Greetings,
I have been attempting to use 32 bit PNG files with an alpha channel. I load the images via SDL_Image. I have my display setup in 16 bit mode. When I call SDL_DisplayFormatAlpha() on my image, my image becomes fully transparent. I.E. I can see right through it and it is as if it was never drawn to the screen. If I do not call the convert function, the images displays just fine, with the alpha pixels blending in beautifully.
I want to be able to convert the surface from 32 bit to 16 bit because 16 bit images draw noticeably faster to the screen. Anyone have any suggestions?
Garak
SDL & Alpha Blending
Re: SDL & Alpha Blending
maybe you should to convert it by yourself:Garak wrote:Greetings,
I have been attempting to use 32 bit PNG files with an alpha channel. I load the images via SDL_Image. I have my display setup in 16 bit mode. When I call SDL_DisplayFormatAlpha() on my image, my image becomes fully transparent. I.E. I can see right through it and it is as if it was never drawn to the screen. If I do not call the convert function, the images displays just fine, with the alpha pixels blending in beautifully.
I want to be able to convert the surface from 32 bit to 16 bit because 16 bit images draw noticeably faster to the screen. Anyone have any suggestions?
Garak
int RoundNumDither(float n)
{
int p=(int(n*10))%10;
if (rand()%10<p) return n+1; else return n;
}
unsigned short Get4444()
{
unsigned short c=0;
int r_=RoundNumDither(float(r)/17);
int g_=RoundNumDither(float(g)/17);
int b_=RoundNumDither(float(b)/17);
int a_=RoundNumDither(float(a)/17);
if (r_>15) r_=15;
if (g_>15) g_=15;
if (b_>15) b_=15;
if (a_>15) a_=15;
if (r_<0) r_=0;
if (g_<0) g_=0;
if (b_<0) b_=0;
if (a_<0) a_=0;
c=(b_) + ((g_)<<4) + ((r_)<<8) + ((a_)<<12);
return c;
}
this is very slow converting, that i am using offline, before saving 16 bit 4444 texture.
I decided to look into the SDL source before trying Tony’s suggestion. It appears that SDL only stores 16 bit image data in 5551 or 5650 pixels formats. The 4444 format does not seem to be a format that your native pixel data can exist in. As such, I don’t think it would do me any good to convert the image to 16 bits. I am guessing that SDL has to have the alpha channeled image in 32 bits, and then does some software blitting to make it blend when the screen is in 16 bit mode.
Can someone confirm if this is the case? Is there a hardware accelerated way to blit images that contain alpha data? The SDL may already be doing this, but it appears to me that it is only using software blits that write directly to VRAM to carry out alpha blits. Any ideas?
Garak
Can someone confirm if this is the case? Is there a hardware accelerated way to blit images that contain alpha data? The SDL may already be doing this, but it appears to me that it is only using software blits that write directly to VRAM to carry out alpha blits. Any ideas?
Garak
The current hw_blit probably fails to support alpha blits (both per pixel and per surface).
I had a quick glance at the source and it would appear to be difficult to support both 5650 and 4444. Neither VideoInit or SetVideoMode seem to provide an interface to request one or the other. It would be nice to blit with a 4 bit alpha per-pixel. But the only way I can see this happening is with an environment variable (perhaps SDL_PSM?).
Right now I'm working on a method to hwaccelerate the rectangles in noiz2sa (it needs an 8bpp hwsurface with an hwpalette). After that I might have some time to look into hw accelerated alpha blits.
I had a quick glance at the source and it would appear to be difficult to support both 5650 and 4444. Neither VideoInit or SetVideoMode seem to provide an interface to request one or the other. It would be nice to blit with a 4 bit alpha per-pixel. But the only way I can see this happening is with an environment variable (perhaps SDL_PSM?).
Right now I'm working on a method to hwaccelerate the rectangles in noiz2sa (it needs an 8bpp hwsurface with an hwpalette). After that I might have some time to look into hw accelerated alpha blits.
I've had problems with the latest version of SDL.
I upgraded to the latest, but things broke, so I rolled back to a version from a month or so ago. I'm blitting a couple of bmps to a 32 bit surface with alpha and in the latest version, alpha doesn't work and the images are skewed.
When I get time, I'll try to determine which commit in SVN changed the behaviour.
I upgraded to the latest, but things broke, so I rolled back to a version from a month or so ago. I'm blitting a couple of bmps to a 32 bit surface with alpha and in the latest version, alpha doesn't work and the images are skewed.
When I get time, I'll try to determine which commit in SVN changed the behaviour.
I've put this into the head revision in svn:
This should make alpha blits work (without hwaccel)... but I'm not sure about skewed images. Perhaps you can point me to the source?
ps: checkout noiz2sa, it now playable even with background ogg music!
Code: Select all
this->info.blit_hw_A = 0; /* todo: implement me */
ps: checkout noiz2sa, it now playable even with background ogg music!
Perhaps you could just change 15 bit graphics mode to be 4444 mode. It could be our little secret =). But seriously, I think it's crucial that SDL support hardware accelerated alpha blits. The psp port is already doing really well as far as speed is concerned, and this would push it over the top in my opinion.
I’ve looked through the source several times, and I’m still not sure as to what is the best mode I should be using for speed in SDL? I have a lot of images with transparent backgrounds. Would 16 bit vs 15 bit modes make a difference in how fast images are drawn? Do you have any advice on what is fatest based on the current SDL setup?
Garak
I’ve looked through the source several times, and I’m still not sure as to what is the best mode I should be using for speed in SDL? I have a lot of images with transparent backgrounds. Would 16 bit vs 15 bit modes make a difference in how fast images are drawn? Do you have any advice on what is fatest based on the current SDL setup?
Garak