CVS Update (alpha blending)

SDL Development
1

do not convert them to the display format. If you convert an image,
you will lose the alpha channel information,

I thought this was not supposed to happen…(and that it would get fixed in
a future version) ?

Dimitris

2

Therefore, computationaly it doesn’t matter whether the source image is
32-bit or another format, and in fact since it’s cheaper to unpack 32 bpp
pixels, it’s actually faster if the source image is 32 bits per pixel.

Unless the hardware has some magic alpha blit support (DirectX?) that
requires a certain format.

I haven’t done enough asm lately to be certain, but I can imagine that
careful use of SIMD instructions can make better code if the format mirrors
the pixel format closely, perhaps blending the RGB components in parallel.

I’m considering dropping alpha channel support for anything other than
32-bpp images, although per-surface alpha would still be avaialble.

Isn’t ARGB4444 used by Voodoo hardware?

I agree that dropping alpha support for anything but (canonicalized)
32-bit ARGB makes implementation a lot easier, though.

3

I happened to need alpha blending for Pirates Ho!

The latest CVS snapshot has 32-bit alpha channel blits nearly twice as fast
as they were before. RLE accelerated blits are also a little bit faster.

http://www.devolution.com/~slouken/SDL/cvs.html

I tested the code by loading a PNG file created by GIMP with the SDL_image
library, and then blitting the resulting image to the screen. I properly
saw the image being blended with the destination surface, according to the
alpha channel information stored in the PNG image.

I recommend that you keep images with alpha channel information as 32-bits,
and do not convert them to the display format. If you convert an image,
you will lose the alpha channel information, and the alpha blits are optimized
for 32 bpp source images.

Enjoy!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

4

do not convert them to the display format. If you convert an image,
you will lose the alpha channel information,

I thought this was not supposed to happen…(and that it would get fixed in
a future version) ?

Possibly.

Think about it for a minute:
You have 32-bit source images, and N-bit screen display.
For alpha blending you have to unpack the source pixels and destination
pixels and mix them together. It is much cheaper to unpack 32-bpp pixels
than it is to unpack N-bit pixels.

Therefore, computationaly it doesn’t matter whether the source image is
32-bit or another format, and in fact since it’s cheaper to unpack 32 bpp
pixels, it’s actually faster if the source image is 32 bits per pixel.

I’m considering dropping alpha channel support for anything other than
32-bpp images, although per-surface alpha would still be avaialble.

Comments?
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

5

I thought this was not supposed to happen…(and that it would get fixed
in

a future version) ?

Possibly.

[snip]

I’m considering dropping alpha channel support for anything other than
32-bpp images, although per-surface alpha would still be avaialble.

That would be OK i guess…i believe most people use 32bit images for images
with alpha channel…

The reason i would like to see DisplayFormat working fine with alpha
channeled images, is not speed (anyway,i am using 32bit images on 32bit
display :slight_smile: It’s just that it’s kind of awkward to keep a list of images
with alpha channels and of those with no alpha and loading them using
different ways (sometimes calling DisplayFormat and sometimes not).

Regards,
Dimitris

6

The reason i would like to see DisplayFormat working fine with alpha
channeled images, is not speed (anyway,i am using 32bit images on 32bit
display :slight_smile: It’s just that it’s kind of awkward to keep a list of images
with alpha channels and of those with no alpha and loading them using
different ways (sometimes calling DisplayFormat and sometimes not).

I could return the same image in the case that no conversion is necessary,
but that would break a lot of code that does the following:

converted = SDL_DisplayFormat(image);
SDL_FreeSurface(image);
...

SDL_DisplayFormat() performs the conversion by simply blitting the source
surface to a newly created surface that has the display pixel format.
The display format doesn’t have an alpha channel, so the resulting
surface doesn’t have an alpha channel. In addition, the conversion blit
uses alpha blending.

Suggestions?

-Sam Lantinga, Lead Programmer, Loki Entertainment Software