Sign in to follow this  
Auriya

*Updated* [SDL] SDL Blitting problem

Recommended Posts

Helloes! I've gotten further with messageboxes blitting, however I have gotten stuck again. ;/ This was done quickly so don't mind the little silly/stupid mistakes or too-much-extra work in it which could have done better or more effecient. :P Here is the .cpp file;
http://pastie.textmate.org/private/4qtemnq8f4sybftjrcf4og
Here is the .h file; (Its actually the text module, but I removed functions and things irrelevant to this topic. ;p
http://pastie.textmate.org/private/jffbf2tp6d1xb01rxcynew
The result is this:
http://i28.tinypic.com/2nv9gnt.jpg
(The exact same box as my old method, except far more optimized. Everything gets blit'd onto a surface, and that surface can be used anytime, so no more directly blitting onto the screen and re-calculating everything every frame. This one works VERY well, except there is something wrong with the transparency? While the result should have been exactly this:
http://i30.tinypic.com/2i0zzux.jpg
(The look of this box works, but it uses my old method which blits directly onto the screen, and has to re-calculate and blit the whole image-sequence of the messagebox every frame, so uses far too much CPU) Now, I am probably doing something wrong, Surfaces that have just been created I've noticed have a black background, so I set a black colorkey to make the surface transparrent, but it just doesn't work, it still gets a some kind of black background. ;/ All images except the background of the text are all transparrent, so it should have worked properly. Any help, tips or explanations would be useful~ Thanks in advance everyone! ~Auriya [Edited by - Auriya on February 22, 2008 7:28:48 PM]

Share this post


Link to post
Share on other sites
It's been a while since I've done anything with SDL surfaces, but I'll have a go at answering...

First off: it doesn't look like you actually need to be setting a colour key. You're loading png's, which have per pixel alpha, so if you've created them to be transparent you probably don't want the colour key as well.

(Note also that the colour key you've picked (r:0 g:0 b:0 a:0) would be transparent anyway, and if you want a surface to be filled with a specific colour, it would be better to fill it with the colour, rather than relying on a surface being created "black" (which might in any case be r:0 g:0 b:0 a:255)).

SDL alpha blending is kinda tricksy IIRC. The best thing to do would be to read the SDL_SetAlpha docs page. This explains the different combinations of using RGBA or RGB and colour keys / per surface alpha.

HTH

Share this post


Link to post
Share on other sites
First thing that looks like bad news is that you are using SDL_CreateRGBSurface to create a surface, then loading an image to the surface causing a memory leak. When loading images using SDL/SDL_image they create a surface in the pixel format of the image file. So, in effect, you create a surface using SDL_CreateRGBSurface which is saved in a pointer, then overwrite the pointer with a new surface created by IMG_Load. To fix this, skip the part that uses SDL_CreateRGBSurface. Your intentions may be for something else but for now you aren't using what this creates anyway.

Moving on. SDL will not use per pixel alpha and color keys together the way you think. From the documentation using SDL_SetAlpha:
Quote:
Alpha effects surface blitting in the following ways:

RGBA->RGB with SDL_SRCALPHA

The source is alpha-blended with the destination, using the alpha channel. SDL_SRCCOLORKEY and the per-surface alpha are ignored.
RGBA->RGB without SDL_SRCALPHA

The RGB data is copied from the source. The source alpha channel and the per-surface alpha value are ignored.
RGB->RGBA with SDL_SRCALPHA

The source is alpha-blended with the destination using the per-surface alpha value. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied. The alpha channel of the copied pixels is set to opaque.
RGB->RGBA without SDL_SRCALPHA

The RGB data is copied from the source and the alpha value of the copied pixels is set to opaque. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied.
RGBA->RGBA with SDL_SRCALPHA

The source is alpha-blended with the destination using the source alpha channel. The alpha channel in the destination surface is left untouched. SDL_SRCCOLORKEY is ignored.
RGBA->RGBA without SDL_SRCALPHA

The RGBA data is copied to the destination surface. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied.
RGB->RGB with SDL_SRCALPHA

The source is alpha-blended with the destination using the per-surface alpha value. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied.
RGB->RGB without SDL_SRCALPHA

The RGB data is copied from the source. If SDL_SRCCOLORKEY is set, only the pixels not matching the colorkey value are copied.

Note: Note that RGBA->RGBA blits (with SDL_SRCALPHA set) keep the alpha of the destination surface. This means that you cannot compose two arbitrary RGBA surfaces this way and get the result you would expect from "overlaying" them; the destination alpha will work as a mask.

Also note that per-pixel and per-surface alpha cannot be combined; the per-pixel alpha is always used if available


In short, you get to use a color key OR alpha blending. You don't get both on one surface (using SDL provided functions anyway).

What I have done in the past to achieve a similar effect is to use a per surface alpha of 128 (this is optimized in SDL) on a solid blue, black or white surface and blit what I need from that to the screen then blit the text and borders using a color key on top of that. This gives the window background a semi transparent look but the text etc. is solid.

Another suggestion I have is using SDL_DisplayFormat or SDL_DisplayFormatAlpha to optimize your surfaces for use with the current screen format. This will make a huge difference with performance.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this