[SDL] a few simple SDL questions

David Olofson david at olofson.net
Wed Jan 29 08:50:01 PST 2003

On Wednesday 29 January 2003 10.19, Cameron Matheson wrote:
> Hi,
> I'm just wanting to write a few little games in SDL, so i have a
> few questions while i try to learn it.
> 1) should alpha not be used?  I've been searching on google and it
> seems that everyone says it is too slow to be any good...

It's dog slow, compared to plain opaque or colorkey blitting, but I'm 
using it a lot in Kobo Deluxe. It's not too slow to be useful; just 
too slow to be used all over the screen. (Note that with RLE encoded 
surfaces, it's only the actual pixels that need alpha that are 
expensive. The rest are just as fast as for opaque or colorkeyed 

> i've also
> read that it works better if you initialize w/ SDL_SWSURFACE
> instead of SDL_HWSURFACE, is this true?

Yes, and that's because alpha generally isn't h/w accelerated. (It can 
be on a few targets, but I'm not sure which ones, or when you can 
trust it to work.)

> Is OpenGL the only good
> way to get alpha right now (i'm not really interested in learning
> GL quite yet)...

Well, yes and no. Using 3D acceleration for advanced 2D stuff seems to 
be the only method that's remotely portable across platforms and 
hardware. Mostly because 3D acceleration is where h/w development 
funding goes, but also because 3D rasterization *IS* 2D rendering by 
all means. Indeed, you have some tools that are sort of 3D oriented, 
but even those can be pretty handy when doing 2D or pseudo 3D 

As to APIs, IMHO, OpenGL is the only alternative, since Direct3D is 
only available on MS Windows. Glide is dead, and AFAIK, there are no 
other significant 3D APIs.

> also, does glSDL have good alpha?

Yes. It uses the alpha blending of the 3D accelerator, which is 
usually about as fast as plain "blitting". Note that it actually uses 
alpha blending instead of colorkeying as well. (Maybe it shouldn't, 
but I'm a bit nervous about "advanced" features and older 3D cards 
built for gaming...)

> 2) is it better for performance if i write my own double-buffering
> code, or initialize w/ SDL_DOUBLEBUF and then call SDL_Flip()
> everytime i refresh the screen?

This depends on what kind of display you get. (Which in turn depends 
on what platform and h/w you're on.)

In short, if you're going to scroll the whole screen, it doesn't 
matter much. If you get "fake" flipping (blitting), you'll be 
rendering in system memory, which is very fast. You also get a full 
screen blit to VRAM for each frame (dog slow), but that can't be 
avoided anyway. If you get real h/w pageflipping, you'll be rendering 
directly into VRAM, and flipping is virtually free. Reading from VRAM 
is *extremely* slow, though, so don't even think about doing alpha 
blending directly into VRAM! (Alpha blending is a read-modify-write 

> 3) How could i initialize an fps counter for my game (sorry i'm
> really at a loss w/ this one) ?

Check SDL_GetTicks() and count rendered frames. Every now and then 
(say every 250 ms), calculate fps from the current frame count and 
the time you started counting, and then reset the counter and grab 
the current time for start time for the next calculation.

Note that you have to make sure you disable retrace sync, if you want 
to use this for engine benchmarking.

Also, if you're only interested in the performance of the *engine* (as 
opposed to the slowness of SDL_Flip() when blitting to VRAM), you'll 
have to time the interesting code on a frame by frame basis. You'll 
need better than millisecond resolution for that, though, so 
SDL_GetTicks() won't help much. You'll have to use some OS or CPU 
dependent solution. (Un*x gettimeofday(), Win32 performance counters, 
Pentium+ RDTSC or whatever.)

//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

More information about the SDL mailing list