dfs@cs.brown.edu (David Sklar) (08/21/90)
I am attempting to use the MacII to run interactive programs that were written for framebuffers before the days of palettes, virtual LUTs, etc. These programs expect the pixel values they draw to *not* be modified before being placed in the hardware framebuffer. Thus, I am bypassing the Palette Manager and trying to get as close to the hardware as possible. I want to be able to set the hardware color table with extreme precision: to set LUT entry 0 and know that entry 0 (exactly) of the hardware LUT is being set. Likewise, to set a pixel in the screen's pixmap to value X and know that exactly X is being placed in the hardware framebuffer. Let's say I want to draw a line in color 0. I have reason to believe (but no proof) that it's not enough for me to simply: 1) Set the port's "fgColor" field to 0 (manually, not using a QD routine) 2) Call QuickDraw to draw the line. Of course, there's no way to for me to verify that a 0 was not placed in the hardware FB. But I believe my pixel values are getting mapped to different numbers, because XOR'ing is not working as one would expect. For example, 1) I specified a white color for LUT entry 0 2) I specified a black color for LUT entry 1 3) I drew an image using only fgColors 0 and 1 (always manually setting the fgColor field) 4) I set the transfer mode to XOR 5) I draw a line using fgColor 1 THE RESULT was *not* an inversion of all pixels touched by the line. It seems the numbers I specify are being mapped to something else before they are placed in the hardware FB. Any help in furthering my understanding of this under-documented method for using Color QD would be appreciated!
d88-jwa@dront.nada.kth.se (Jon W{tte) (08/22/90)
In article <DFS.90Aug20184133@dooby.cs.brown.edu> dfs@cs.brown.edu (David Sklar) writes: >Let's say I want to draw a line in color 0. I have reason to believe (but no >proof) that it's not enough for me to simply: > 1) Set the port's "fgColor" field to 0 > (manually, not using a QD routine) > 2) Call QuickDraw to draw the line. Actually, that is "set the ports RGBFgColor to the value of X" fgColor is old-style color, with only 8 predefined colors available. On a 24bit deep screen, this will work: RGBForeColor(&colors[index]); MoveTo(x1, y1); LineTo(x2, y1); If you don't have a 24bit deep screen, you'll have to resort to something called "Animated Colors" (and hope the hardware supportsit, most 8bit h/w actually does) OR hope for the best with tolerant colors with a tolerance of 0. IM V should help you along. >Of course, there's no way to for me to verify that a 0 was not placed in the >hardware FB. But I believe my pixel values are getting mapped to different >numbers, because XOR'ing is not working as one would expect. For example, You want to XOR into video index memory !? You'll have to blast the bits yourself. This gets VERY complicated VERY fast (like, don't forget to switch the computer into 32bit mode if 32bit QD is running &c) h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
lsr@Apple.COM (Larry Rosenstein) (08/22/90)
In article <1990Aug21.182827.19315@nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes: > >Actually, that is "set the ports RGBFgColor to the value of X" >fgColor is old-style color, with only 8 predefined colors available. I originally thought so too. But a color GrafPort also has a fgColor field, which might be a cache of the index of the foreground color. (It may even be at the same offset as fgColor in an old port, I didn't check.) > >On a 24bit deep screen, this will work: > > RGBForeColor(&colors[index]); I doubt that you'd want to have an array of all 16 million colors. Don't you just take the low order 3 bytes of index and transfer them to the high-order bytes of the red, green, & blue fields of the RGBColor? I'm not sure how you would get QuickDraw to set the high-order byte. >You want to XOR into video index memory !? You'll have to blast the >bits yourself. This gets VERY complicated VERY fast (like, don't forget Actually you can use patXOR mode with color, provide you remember that QuickDraw uses the pen patterns in the transfer mode. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
d88-jwa@dront.nada.kth.se (Jon W{tte) (08/22/90)
In article <9880@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >>Actually, that is "set the ports RGBFgColor to the value of X" >>fgColor is old-style color, with only 8 predefined colors available. >I originally thought so too. But a color GrafPort also has a fgColor field, >which might be a cache of the index of the foreground color. (It may even >be at the same offset as fgColor in an old port, I didn't check.) Well, this certainly seems both documented and stable... (Heavy Irony :-) >> RGBForeColor(&colors[index]); >I doubt that you'd want to have an array of all 16 million colors. Don't Of course not. He wanted to have his own lookup table, with indicies from 0 to 255. Thus, you create: RGBColor colors[256]; int index; You're not guaranteed to get the colors you want this easily on less- than-24-bit screens, though (thus the Pallette manager) >>You want to XOR into video index memory !? You'll have to blast the >>bits yourself. This gets VERY complicated VERY fast (like, don't forget >Actually you can use patXOR mode with color, provide you remember that >QuickDraw uses the pen patterns in the transfer mode. Well, he wanted to xor the INDICIES, not the colors. Like, say 0 == blue, and 1 == red, and 2 == black and 3 == green: DrawInColor(1); /* Gives a red drawing */ XORWith(2) /* Makes the red pixels green, and the blue black */ This is an old approach to video handling, but he said he was porting old applications... h+ Jon W{tte, Stockholm, Sweden, h+@nada.kth.se
lsr@Apple.COM (Larry Rosenstein) (08/23/90)
In article <1990Aug22.110820.8154@nada.kth.se> d88-jwa@dront.nada.kth.se (Jon W{tte) writes: > >Well, he wanted to xor the INDICIES, not the colors. Like, say 0 == blue, >and 1 == red, and 2 == black and 3 == green: > >DrawInColor(1); /* Gives a red drawing */ >XORWith(2) /* Makes the red pixels green, and the blue black */ You can do this with Color QuickDraw. Simply make a pix pat (using MakeRGBPat) that is pure black, and use patXOR mode. It will XOR the pixel values (indices). -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr