On 09/17/2010 04:32 PM, Florian Klaempfl wrote:
Am 15.09.2010 17:05, schrieb Nikolay Nikolov:
On 09/15/2010 05:48 PM, Florian Klaempfl wrote:
Am 15.09.2010 16:39, schrieb Nikolay Nikolov:
and then introduce TP7-compatible MaxColors, PaletteType and
procedures/functions. They'll be made optionally hookable (so the go32v2
implementation will be able to implement them with the real EGA palette
registers for maximum compatibility), with a default implementation that
works on top of SetRGBPalette (similar to the way SetPalette is
implemented now)
What do you think?
But this will break existing FPC code, right? I'am also not sure if the
palettes as they are done were invented for other OSes e.g. Amiga or
Atari
Yes, it'll break existing FPC code (but will also improve TP7
compatibility),
I guess most people depend now on FPC compatibility so I'd prefer to
leave it as it is.
Ok then, what about adding the ExtendedRGBPaletteRange (or some similar
name - BGICompatibleRGBPaletteRange?) global variable, that allows using
0..63 range in SetRGBPalette, when set to false (or true, if it's called
BGICompatibleRGBPaletteRange)? We can still make FPC compatibility
(0..255) the default, so existing FPC applications won't break and TP7
applications would be able to easily enable the TP7-compatible range
0..63. At least in the case of 256-colour modes (SVGA256.bgi) this means
pretty much 100% TP7 palette compatibility (when porting code from TP7
to FPC, all the other palette differences only affect 16-colour modes,
because TP7's PaletteType, SetPalette, SetAllPalette, etc. have no
effect in 256-colour modes).
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
