A few simple SDL questions

SDL Development
1

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… i’ve also read that it works
    better if you initialize w/ SDL_SWSURFACE instead of SDL_HWSURFACE, is this
    true? Is OpenGL the only good way to get alpha right now (i’m not really
    interested in learning GL quite yet)… also, does glSDL have good alpha?

  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?

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

Thanks,
Cameron Matheson

2
  1. 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?

If you’re an expert in directx then you might be able to write
faster functions, but in general, you’re well off using SDL. Use
hardware surfaces with sdl_flip otherwise performance will
suffer.

  1. How could i initialize an fps counter for my game (sorry i’m really at a
    loss w/ this one) ?

float total_time = 0;

t1 = SDL_GetTicks();
game_loop();
frame_count++;
t2 = SDL_GetTicks();

total_time += (t2-t1)/1000.0;
fps = frame_count/total_time;
if(frame_count==10) {
total_time = 0;
frame_count = 0;
}

This gives you an ‘average’ fps, for every 10 frames. You can
modify this to suit your requirements.–
hth,
Pallav.

Ralph’s Observation:
It is a mistake to let any mechanical object realise that you
are in a hurry.

| |
|Pallav Nawani |
|Sasken Communication Technologies Ltd. |
|Domlur, Bangalore. |
|_______________________________________________________________|

3

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
surfaces.)

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
rendering.

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…)

  1. 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
operation.)

  1. 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 —On Wednesday 29 January 2003 10.19, Cameron Matheson wrote: