[SDL] Combining per-pixel and per-surface alpha

[David Olofson]

On Wednesday 26 December 2001 18:00, RaFaL Pocztarski wrote:
> I was going to write a simple fireworks demo, using small RGBA sparks
> with decreasing per-surface alpha, but "per-pixel and per-surface alpha
> cannot be combined; the per-pixel alpha is always used if available"
> (from http://sdldoc.csn.ul.ie/sdlsetalpha.php).
>
> So I think I could write some code for SDL to support combination of
> per-pixel with per-surface alpha. For per-surface alpha 0, there'd be
> no blitting, for 255 normal alpha blitting would be used, and for
> everything between 1 and 254 every pixel's alpha value would be
> multiplied by per-surface alpha and shifted 8 bits right (yes, it
> should be divided by 255, not 256 but it'd be much faster that way),
> except maybe 128 and other powers of two where single right shift could
> be used.

Well, it would be a nice feature to have, but 3 or 4 multiplications and 
the same number of shifts extra per pixel (plus the extra shuffling 
around between registers for crap CPUs like x86) will result in quite a 
performance hit - and alpha blending is slow enough as it is.

However, if it got in, I could remove the "RGBA XOR surface alpha" logic 
in glSDL without breaking SDL compatibility. ;-)

(Actually, I can probably remove it anyway, as any code that would be 
affected is broken.)


> I'm also thinking about other "modes" of blitting surfaces, similar to
> other than normal modes of displaying layers in Gimp, from which the
> addition mode would be best for fireworks.

Additive blending is indeed useful, but unfortunately the required 
saturation checks could be even slower than multiplications! (On Pentium 
MMX and later, with 3 cycle MUL, that is.)

An MMX implementation could easilly be very, very fast, though, as MMX 
has both saturating operations and test instructions that generate masks 
rather than change the instruction flow.


> What do you think? I know it'd be slower and hardware acceleration
> couldn't be used (especially for such addition mode etc.),

Currently, h/w acceleration cannot be used even for plain alpha, so 
that's not really an argument.

Anyway, h/w acceleration *can* be used for various blending operations 
other than alpha. All you need is a driver and an API that support it. 
Look at the OpenGL blending control - most 3D cards accelerate most of 
the modes you can set up with it. (At least I know for sure that both 
alpha and additive works on the G400. :-)


> but it still could be useful. Maybe there's already someone working on
> it?

Well... I can just remove two or three lines on glSDL, and voila! ;-)


//David Olofson --- Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
|      Multimedia Application Integration Architecture      |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'