[SDL] SDL_DisplayFormatAlpha() and 16-bit surfaces

[Tim Allen]

On Tuesday, August 6, 2002, at 05:21 , Adam Gates wrote:
> Chris Thielen wrote:
>
>> On Mon, 2002-08-05 at 22:49, Tim Allen wrote:
>>> It would be nice if there were some way of taking a surface with 
>>> colour-key alpha, and transforming it to a surface in the display 
>>> format with colour-key alpha, rather than a surface in the display 
>>> format with 8-bits of alpha which are either 0 or 255 for any given 
>>> pixel - I'm sure colour-key alpha, especially with RLE encoding, 
>>> would be faster than doing proper alpha-blending. If you're blitting 
>>> to a 16-bit surface, I'm sure doing the 32->16 bit conversion is 
>>> wasteful, too.
>>>
>> Yea, that's why I'm wondering this, I'd like to avoid 32->16 bit
>> conversions I'm doing right now. It's not too big a deal because the
>> majority of the screen isn't updated every frame, and not all the
>> sprites need alpha, so not all are 32-bit, but it's still a waste to
>> convert it from 32 to 16 on every blit, I agree.
>> -- chris (chris at luethy.net)
>
> Are you concerned about this because the screen surface is 16-bit?
> But the screen surface doesn't have alpha, does it?
> If it doesn't then 16-bit RGBA -> 16-bit RGB is just as costly in 
> conversion.

But a surface with colour-key alpha is stored as RGB, not RGBA. So if 
you take a surface with colour-key alpha and run it through 
DisplayFormatAlpha, then you have the RGBA -> RGB conversion as well as 
the 32-bit -> 16-bit conversion.

All I really want is 16-bit RGB -> 16-bit RGB (ignoring pixels of a 
certain colour).