On 07 Jul 96 Derek Benner said to Bryan Smith...
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.
 DB> non-standard XOR values.  If you assume that your sprites are limited
 DB> to 20 to 30 colors, this will probably bring that number down to 20-50
 DB> logical palettes that will need to be initialyzed (This is a
 DB> guesstimate, NOT a rigorous analysis!)  Would that work for an average
 DB> application?  Probably.
The "XOR value" is presumably determined by the colour of the text that you
BitBlt with.  If it is white text on black background, the background XOR
with $0 does nothing, and the foreground presumably XOR's with the 4-bit
colour white, or $F - that's the way it behaves.  So I guess I can change
the colour of the sprite by juggling the colour of the text that I blit
with.  Will try it out, thanks for your suggestion.
I don't understand this palette stuff at all.  I'm running 256 colour, but
it often seems that I am still restricted to 16 colours, e.g. the screen
main background may be one of 256, but the background colour for text
written over that background seems to find the "nearest of 16" colour.
--- PPoint 2.00
---------------