[fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

  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).