SDL surfaces have several attributes that control transparency:
- The SDL_COLORKEY flag and the colourkey value, which indicates one
pixel value that will be transparent - The SDL_SRCALPHA flag and the per-surface alpha value, which sets
a blending factor for the entire surface - The alpha channel, consisting of an alpha value for each pixel
Colorkey and per-surface alpha can already be combined: the result is
that only pixels not matching the colorkey are copied, and blended
with the alpha value onto the destination. This combination can even
be RLE accelerated.
But what about the other combinations?
surface alpha + alpha channel:
We could combine the alpha values for each pixel, but that would be even
slower than the per-pixel alpha blending, and I don’t think there is much
need. We could write a slow catch-all routine but that would be used even
less.
I suggest the alpha channel takes precedence, since it is an integral part
of the image and surface alpha isn’t.
surface alpha + colour key:
A color key just duplicates part of the functionality of an alpha channel
(to select relevant areas of an image for blitting), so it would make
sense to let the alpha channel take precedence here, too, unless someone
comes up with a good reason to keep it. Alternatively the combination
could work (blit each pixel with its alpha value, except those matching
the colour key), for a slightly higher cost.
surface alpha + alpha channel + colour key:
Probably never an intended combination, so any behaviour would do.
The last peculiar case is having an alpha channel but not SDL_SRCALPHA
set. Should the alpha channel be used anyway?
Please tell me if you think I’ve missed something. SDL’s sense of alpha
will be inverted back to sanity (now it’s transparency, it will be changed
to opacity) quite soon, and it’s important that we get all cases correct.