Alpha Blending (Transparency) Examples.

[Presto]

In my current game engine, I've got my own surface class where I have the 565 layer and alpha layer separate. But I also store the layers as separate PNG images as well. I use the SHLoadImageFile function to load the PNGs into a HBITMAP object, and then a variation of PocketFrog's code to make sure it's in 565 format before transferring the data to my surface class.

The surface class has the following member variables:
int m_iWidth, m_iHeight;
BYTE *m_pPixels, *m_pAlpha;
So the m_pPixels variable is sized based on m_iWidth*m_iHeight*2 and m_pAlpha is only half that size.

I've also got my own blit function that takes into account if the image has an alpha layer, and then uses Tala's single-multiply blending function, which is linked to earlier in this thread.

My new game engine is still evolving, but it works incredibly well for this stuff, and almost all of the little tidbits I use can be found scattered in the forums here.

[Cardinal]

I've extend the PocketHal surface class (called TSurface) and added methods that operate directly on the encapsulated surface. So I can blit another TSurface object into this one, I can draw lines, points, triangles, get the byte pointer and what not.

I too store my pixel and alpha data seperatly. Alpha data is a byte array in the range of 0-31. So the blit alpha routines look to that array for per-pixel operations.

[Kzinti]

You want to use 0-32 as the range, not 0-31. Otherwise you can't represent fully opaque. Consider this:

With alpha = 31, you get:

(31 red * 31 alpha) >> 5 == 30 red
(63 green * 31 alpha) >> 5 == 61 green

This is not good.

With alpha = 32, you get:

(31 red * 32 alpha) >> 5 == 31 red
(63 green * 32 alpha) >> 5 == 63 green

This is what you want. The original code by Tala does specify the input alpha to be from 0 to 32.

[Cardinal]

My bad you are correct!