OK, this is roughly what the discussion on #sdl has resulted in. Please tell
me if I got anything wrong.
RGBA->RGB:
SDL_SRCALPHA set:
alpha-blend (using alpha-channel)
SDL_SRCCOLORKEY ignored
SDL_SRCALPHA not set:
copy RGB
if SDL_SRCCOLORKEY set, only copy the pixels matching the RGB
values of the source colour key, ignoring alpha in the comparison
RGB->RGBA:
SDL_SRCALPHA set:
alpha-blend (using the source per-surface alpha value);
set destination alpha to opaque
SDL_SRCALPHA not set:
copy RGB, set destination alpha to opaque
both: if SDL_SRCCOLORKEY set, only copy the pixels matching the
source colour key
RGBA->RGBA:
SDL_SRCALPHA set:
alpha-blend (using the source alpha channel) the RGB values;
leave destination alpha untouched
SDL_SRCCOLORKEY ignored
SDL_SRCALPHA unset:
copy all of RGBA to the destination
if SDL_SRCCOLORKEY set, only copy the pixels matching the RGB
values of the source colour key, ignoring alpha in the comparison
RGB->RGB:
SDL_SRCALPHA set:
alpha-blend (using the source per-surface alpha value);
SDL_SRCALPHA not set:
copy RGB
both: if SDL_SRCCOLORKEY set, only copy the pixels matching the
source colour key
OK, this is roughly what the discussion on #sdl has resulted in. Please tell
me if I got anything wrong.
Looks good to me.
Just to fill everyone in, we’re talking about overhauling the alpha semantics
so they make a lot more sense: flipping the meaning of alpha, adding a fill
function that knows about the alpha channel, and precisely defining the
behavior of blits between various alpha and non-alpha surfaces.
The purpose of this is not to create a full suite of alpha blending modes,
(an add-on library?) but to round out and speed up the current alpha support
in SDL.
Kudos go to Yorick who is doing nearly all of the actual implementation, as
well as adding support for the SDL_RLEACCEL flag which speeds up alpha blits
by a factor of 2-3 or more. 
Take care!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Kudos go to Yorick who is doing nearly all of the actual implementation,
(What a NEEEERRRRDDD!)
-bill!
(who LIKES alpha blending and talked about it a lot while explaining GIMP in
the Linux course he’s helping teach this week )
What do you folks think of allowing 8-bit palettized surfaces to have
alpha in the palette colors?
One example of this feature being useful would be so that nice font
libraries like FreeType 2 modified SDL_ttf could store 8-bit surfaces
for each character, and change the palette to change colors, instead of
allocating a 32-bit RGBA surface and having to render from 8-bit to RGBA
manually every time.
So, maybe if an 8-bit surface has SRCALPHA set to 0 (per-pixel), the
alpha values in the palette colors would be used; if SRCALPHA is set to
a constant (per surface), they would not be used; if SRCALPHA not set,
treat as RGB.
What do you folks think of allowing 8-bit palettized surfaces to have
alpha in the palette colors?
One example of this feature being useful would be so that nice font
libraries like FreeType 2 modified SDL_ttf could store 8-bit surfaces
for each character, and change the palette to change colors, instead of
allocating a 32-bit RGBA surface and having to render from 8-bit to RGBA
manually every time.
So, maybe if an 8-bit surface has SRCALPHA set to 0 (per-pixel), the
alpha values in the palette colors would be used; if SRCALPHA is set to
a constant (per surface), they would not be used; if SRCALPHA not set,
treat as RGB.
It’s an interesting idea. This would of course only work with software
surfaces. Yorick?
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
What do you folks think of allowing 8-bit palettized surfaces to have
alpha in the palette colors?
There are lots of tricks you can do with 8-bit surfaces and lookup tables;
SDL can only cover the very basics. The one you describe is interesting
and occasionally useful (and both TGA and PNG support per-index alpha values
for colormapped images).
One example of this feature being useful would be so that nice font
libraries like FreeType 2 modified SDL_ttf could store 8-bit surfaces
for each character, and change the palette to change colors, instead of
allocating a 32-bit RGBA surface and having to render from 8-bit to RGBA
manually every time.
Last time I had to do this I rendered the font in 8-bit greyscale (where
0 = transparent, 255 = opaque, essentially just rendering the alpha
channel of the glyphs) and then used a look-up table for each colour.
No doubt SDL_ttf can be persuaded to do this.
Anyway, since it isn’t hard to write platform-independent code that does
this in the application that needs it (or maybe in a library like SDL_ttf),
I don’t think it’s necessary to put it into SDL, unless someone
bribes^Wpersuades me otherwise
Kudos go to Yorick who is doing nearly all of the actual implementation,
(What a NEEEERRRRDDD!)
Run Bill!! He’s after you!
MartinOn Wed, 9 Aug 2000, William Kendrick wrote:
Bother! said Pooh, as @TO decompressed the airlock.
“Michael Chen” wrote in message
news:39922E1E.60107 at ensoniq.com…
What do you folks think of allowing 8-bit palettized surfaces to have
alpha in the palette colors?
One example of this feature being useful would be so that nice font
libraries like FreeType 2 modified SDL_ttf could store 8-bit surfaces
for each character, and change the palette to change colors, instead of
allocating a 32-bit RGBA surface and having to render from 8-bit to RGBA
manually every time.
So, maybe if an 8-bit surface has SRCALPHA set to 0 (per-pixel), the
alpha values in the palette colors would be used; if SRCALPHA is set to
a constant (per surface), they would not be used; if SRCALPHA not set,
treat as RGB.
I’m in favor. It’s useful, it fits in with the rest of SDL, it makes 8 bit
surfaces more consistant with other surfaces, and it has no great cost
associated with it.–
Rainer Deyke (root at rainerdeyke.com)
Shareware action/role-playing games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor