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]

Updated the topic, hopefully this'll be understandable since I suck at explaining problems. >_<

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.