BS> Problem is, it does not seem to work like that with the Canvas.  For
BS> example, if the canvas color is clBlue = $00FF0000, and you BitBlt in
BS> some white-on-black text using the SRCINVERT operator, you might 
BS> expect toget clYellow $0000FFFF text, but you get clOlive $00007F7F.  
BS> Likewise if the
BS> canvas is clNavy, $007F0000 then you get clYellow $0000FFFF text.
BS> It seems to behave as though what is being XOR'ed is not the clNavy 
BS> LongIntrepresentation of $007F0000 but rather a 4-bit "DOS text 
BS> foreground colour"
BS> representation of clNavy as $1, where 1=blue, 2=green, 4=red, 
BS> 8=brightness.The NOT of $1 (dark blue) is $E, i.e. bright yellow, 
BS> which is what you in
BS> fact see.
Actually, now that you mention it, you're right!  When VB or other programs 
specify the '32-bit' "VALUE" of the color, they are not being totally honest. 
 IF, and ONLY IF, the system is running in 24-bit, 'true color' mode, will 
the system directly work with the 32/24-bit color values. If the computer 
system is running in 256-color palette mode, the system will used the byte 
index into the color palette-AND, as you have seen, you will get some hokey 
value.   
 
The correction for this is to use the ColorToRGB and RGB functions to switch 
from the index value to the true RGB color breakouts and THEN perform the 
XOR, calling RGB to put the NEW value back to a byte index value.  However, 
this STILL causes a problem.  Can anyone see it?!?   
 
You see, if you haven't stuffed the proper LongInt values for the XORed 
colors into the palette, you will get a 'nearest matching' value, NOT the 
exact XOR, because the system will NOT use the exact values unless they are 
either ALREADY in the System Palette or you have used RealizePalette to move 
the exact 24/32-bit values from a custom Logical Palette to the System 
Palette. 
 
Here ANOTHER problem arises.  From what you're writing, I'm making the 
assumption that you DO want the EXACT true-color XOR value.  That means 
you've got to have each possible XOR value stuffed into a Logical Palette, if 
you are running in 256 color mode.  Well, a full RGB 24/32-bit value runs to 
16+ MILLION colors and at 256 colors per palette, that means you're going to 
need to have 64,536 palettes sitting out there or you're going to have to add 
code to update your logical color palette on the fly.  Either way, I don't 
envy you if this is what you want to accomplish.  Now, if you're already 
limiting yourself to the basic 256-color system palette AND you don't mind 
doing a little work, then you can just determine the set of possible XOR 
values for your sprite against the system palette and create the few logical 
palettes needed to hold any non-standard XOR values.  If you assume that your 
sprites are limited to 20 to 30 colors, this will probably bring that number 
down to 20-50 logical palettes that will need to be initialyzed (This is a 
guesstimate, NOT a rigorous analysis!)  Would that work for an average 
application?  Probably. 
 
Hope this helps. 
 
Derek
--- FreeMail 1.07b
(1:203/21)
---------------