Image Transparency In Sdl


Sadistictoaster

Still Fresh
Joined
Sep 12, 2006
Messages
22
Hey

Have been experimenting with the following for image transparency

SDL_SetColorKey(screen, SDL_SRCCOLORKEY, SDL_MapRGB( screen->format, 0x00, 0x00, 0xff ));

However , it really slows things down. Any quicker way of doing image transparency with SDL? It also doesn't seem to work quite properly , the images seem to get blurred as they move.

Many thanks in advance
 
Only way I can think of and it probably does the same is to set the transparency in your image such as a .png

I haven't checked or noticed if there is a performance hit with transparency on sdl. are you using hw acceleration libs?
 
> are you using hw acceleration libs?


No , did play around with it , but the screen went all flickery. Might try switching from .bmp's to .png's with transparency built in , see if that helps
 
However , it really slows things down.

Color key can really slow down the images if they are not in the same format as the display.
I assume you are not trying to put a colorkey on the actual screen because I don't think that would work?

Anyway if you want to load up an image with a colorkey and have it running at full speed, do it like this:

Code:
SDL_Surface *myimg, *temp;
temp = SDL_LoadBMP("myimg.bmp");
SDL_SetColorKey(temp, SDL_SRCCOLORKEY, SDL_MapRGB(temp->format, 0x00, 0x00, 0xff));
myimg = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);

That should be almost as fast as blitting without a colorkey.

Using bmps or pngs won't make a difference as they are all converted in to raw data when loaded by SDL or SDL_Image.
 
Last edited by a moderator:
I wonder, why use SDL_MapRGB(temp->format, 0x00, 0x00, 0xff) instead of directly write 0x0000ff ?
I mean, it's easy : 2 first hexa numbers for Red, 2 seconds for Green, and 2 lasts for Blue!
Calling another SDL fonction will robably slow down a little, will it? so why use it? compatibility issue?
 
> are you using hw acceleration libs?


No , did play around with it , but the screen went all flickery. Might try switching from .bmp's to .png's with transparency built in , see if that helps
That's the main part of your problem right there. You need to be using the hw libs with a hw surface otherwise SDL will be very slow at blitting. The reason the screen went all flickery is probably because you didn't enable double buffering. On a sw surface, when you call sdl_flip it will just tell the screen to update, but on a hw surface it will tell it to switch to the other buffer. If you didn't enable double buffering then it will switch to a black surface instead. Then when you're using hw surfaces, make sure you use sdl_displayformat like Dr_Ian says, which will set your graphic to also use hw.
 
Last edited by a moderator:
I wonder, why use SDL_MapRGB(temp->format, 0x00, 0x00, 0xff) instead of directly write 0x0000ff ?
I mean, it's easy : 2 first hexa numbers for Red, 2 seconds for Green, and 2 lasts for Blue!
Calling another SDL fonction will robably slow down a little, will it? so why use it? compatibility issue?

If you load up a 16bit or an 8bit image then 0x0000ff will not be the right colour.
 
Last edited by a moderator:
I wonder, why use SDL_MapRGB(temp->format, 0x00, 0x00, 0xff) instead of directly write 0x0000ff ?
I mean, it's easy : 2 first hexa numbers for Red, 2 seconds for Green, and 2 lasts for Blue!
Calling another SDL fonction will robably slow down a little, will it? so why use it? compatibility issue?

If you load up a 16bit or an 8bit image then 0x0000ff will not be the right colour.

sounds good, but as long as i'm getting started with SDL and know what images i'm using, I will use a simple 0xffff format :)

Another question : is guess it is faster to write it directly rather than calling SLD_MapRGB, isn't it? Apart from the 16b/8b issue?
 
Last edited by a moderator:
Another question : is guess it is faster to write it directly rather than calling SLD_MapRGB, isn't it? Apart from the 16b/8b issue?
It would be an almost unnoticeable amount slower to call maprgb, but you only need to call it once when you set the color key not every time you blit, so it wouldn't really matter how slow it was.
 
Last edited by a moderator:
Dr_Ian : You've cracked it , thanks :) Running beautifully now , so fast I think I'll need to artificially slow it down :)

woogal : Will try your idea about hw libs next time I've got a minute.

Thanks all
 
Back
Top