[SDL] a few simple SDL questions
david at olofson.net
Wed Jan 29 08:50:01 PST 2003
On Wednesday 29 January 2003 10.19, Cameron Matheson wrote:
> 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