Programming with SDL - Tutorial 4
Introduction:
After a bit of a wait, I've finally found some time to sit down and type the fourth tutorial in this series. I'd like to thank everyone that has emailed me with suggestions, improvements, or encouragement.
First, a few corrections. Please note that the SDL_LockScreen function needs to be used only when accessing the surface's image data. (This is the actual pixel data for the surface.) Functions such as SDL_BlitSurface should NOT be called on locked surfaces. There was a small calculation error in the setpixel function, when the setting a pixel in a 16 or 15 bits per pixel display; this has been fixed as well. Surface locking is an issue with more complications in Windows. (Look for a Windows specific tutorial soon on issues like this.)
At the end of the last tutorial, we had loaded a couple bitmaps, and put them on the screen. While it's nice to see something other than random pixels on the screen, there are a couple issues with just loading standard bitmaps, the first of which is handling transparency.
The Problem:
Using the code from the last tutorial - simply loading Bitmaps and placing them on the screen, it's not possible to have nice rounded sprites, or sprites that have some of the background showing through.
Transparent vs. Opaque Sprites
When drawing a simple ball for example, the it's obvious you don't want the black background of the image showing through. SDL provides two methods of handling this. I'm going to cover the first in this tutorial, and touch a bit on the second. - The second method will be a tutorial in itself. Stay tuned.
The First Method: Color Keying:
Color keying is a very simple but very expensive process. It is very similar to the popular "blue screen" technique involved in making movies: a color is selected, and while drawing the image, any pixels of this color are not drawn, allowing the background to show through.
Problems with Color Keying:
There is no such thing as a free lunch, and color keying is no exception. As mentioned before, color keying is expensive. This issue takes a back seat to the more apparent limitations of color keying. Color keying doesn't allow for partial transparency. This creates jagged edges, or even worse, edges where the color key becomes painfully obvious - the example program included with this tutorial uses an image purposely chosen to demonstrate this. IT'S A FEATURE NOT A BUG.
Color Keying with SDL:
So, that's all nice and good. But, how do you do it?
The first step is to load the image into an SDL surface. I the tutorial, I do this using SDL_LoadBMP with a small, ball-like image. Then, it's a simple item of setting the color key using SDL_SetColorKey. This function accepts a few parameters: the surface to add the key to, a parameter telling SDL operation you want to add to the image, and the color key itself.
The second parameter is important as it allows you to perform operations in addition to color keying. The major use here is to add Run Length Encoding(RLE) to an image. RLE compresses the image, allowing it to use less memory, and occasionally giving a slight increase in speed. RLE only works well when the image uses few colors, with large blocks of a single color.
The SDL color key is specified by a color, usually mapped using SDL_MapRGB.
SDL_SetColorKey(ball, SDL_SRCCOLORKEY, SDL_MapRGB(ball->format, 0, 0, 0));
Adding a color key to a surface named ball.
In this example, I set the color black to be transparent. This can be any color - if you dislike black, a bright yellow or blue works as well. Further, it's possible to set different color keys to different sprites. If you want to use blue and black color keys on different images to cater to the images contents - then DO IT. While RLE encoding isn't often useful, but it's easy to add:
SDL_SetColorKey(ball, SDL_SRCCOLORKEY|SDL_RLEACCEL, SDL_MapRGB(ball->format, 0, 0, 0));
RLE encoding is performed the first time the surface is used.
To change the color key, simply call SDL_SetColorKey with a different key. To remove a color key, simply call the SDL_SetColorKey function with the second parameter set to zero.
Introduction Alpha Blending (beginner):
Alpha blending could very well make up a tutorial on its own. This tutorial will provide a brief introduction to Alpha blending.
Alpha blending allows for images to have partial transparency. Normally images contain Red, Green, and Blue values that when combined translate to the color you see on the screen. Alpha blending adds another "channel" - the Alpha Channel. The Alpha value represents how "clear" a particular pixel or image is. Using SDL an Alpha value of zero specifies an image that is completely transparent, while an Alpha value of 255 is opaque.
Note: These Alpha values where reversed in earlier version of SDL, to make sure everything works properly, use the latest stable version of SDL..
Setting the Alpha Properties of a Surface:
While not allowing for transparency of different portions of the image (like color keying), per surface alpha channel let us have an entire sprite have see through qualities. This is done using the SDL_SetAlpha function, which works much like SDL_SetColorKey. This function must be passed a surface, a flag specifying the operation, and an alpha value.
SDL_SetAlpha(bumper, SDL_SRCALPHA, 128);
Adds an alpha channel to the surface bumper making it half transparent
To remove the Alpha channel, pass SDL_SetAlpha zero as the second parameter. In addition to setting the surface Alpha, this function can add RLE in the same manner as the SDL_SetColorKeyFunction.
Finishing Up:
Hopefully, you have an idea of how to handle Alpha blending and color keying on a per surface level. I'm working on the next set of tutorials right now, which will include a bit more on graphics, but also branch out to input and event handling.
The backdrop image was snagged from the KDE background collection, see the information with the kdeartwork package for redistribution rights.
/me closes the mighty vim editor. 'Till next time.
Functions Covered in this Tutorial: SDL_SetAlpha, SDL_SetColorKey
Code: tutorial4.tgz