"Premature optimization is the root of all evil."

Somethings I do, when I need to:
>Hardware surfaces for blits.
>16-bit color (who really needs 32 or 24? Unless you are making a professional game, it is a waste of time)
>Either having a double buffer and blitting EVERYTHING to screen, or having a single "background" surface to act as a blitting buffer. Don't use both.
>Small screen size (again, 640x480 full screen is big enough for most ameuter stuff)
>Full screen

Most of these are lame, common sense things, but they work.

I remember Drew_Benton did a lot of experimentation into how to get good performance out of SDL, can't seem to find the thread though.

The basic thing to keep in mind with SDL is that you're dealing with a fill-limited situation. Keeping the size of the screen small (640x480 is probably the max I'd recommend) will help, as will minimizing the amount of blit calls you do.

Additionally, there are a bunch of issues with using hardware vs. software sprites, RLE and a bunch of other stuff. I think I recall Drew mentioning that software surfaces are actually faster than hardware cases in many cases, and that RLE slows stuff down.

Again, you'd have to find his thread, or ask him directly.

Creating an orthoganal OpenGL context and using that for the graphics plotting if you're using alpha-blending, scaling or image rotation to any extent. And this is one situation that premature optimization isn't necessarily the root of evil since OpenGL has more direct support of accelerated graphics hardware.

One thing is to make sure that all your surfaces are in the same format as the display format. That can make a huge difference.

Check out SDL_DisplayFormat() and SDL_DisplayFormatAlpha() if you haven't already.

// cryon

Quote:Original post by Rob Loach

Quote:Original post by ender7771
"Premature optimization is the root of all evil."

I tend to live by this rule. A good general rule is to implement your complete gameplay, with the nicest design you can come up with, and then worry about its optimization later on. I ran into a few problems with Blastoids as slow computers couldn't handle the realtime surface rotations. In order to combat the issue, I implemented a graphics setting, in which the player could choose to run the game at low graphics detail, or high graphics detail... Worked very nicely.

Have you considered pre-rendering 16 or so different angles for your spinning sprites, so you never have to do those expensive calculations in-game? Most players wouldn't tell the difference.

>16-bit color (who really needs 32 or 24? Unless you are making a professional game, it is a waste of time)
Took me to implement
>Check out SDL_DisplayFormat() and SDL_DisplayFormatAlpha() if you haven't already.

Wow, you really saved me here

I was banging my head against the wall, using profilers (with the hint that
it had to do with blitting, at SDL_UpperBlit was taking 75% of all the time)

I was hitting 40fps tops and now I hit around 125fps-140fps just because of the preparing of surfaces with SDL_DisplayFormat.

I thought I read that SDL_BlitSurface made a call to SDL_DisplayFormat the first time you blitted, apparently I was mistaken.


>"Premature optimization is the root of all evil."

I totally agree, but there are cases when you can't even debug the game
because is running in sub "eye-capture" framerates, or with choppy lagged audio,
and you really can't tell if it's a performance problem or conceptual errors.

So keeping in mind optimization, but not putting to much mind to it is a good choice. THE Zen choice, heh.



-Martín



p.s.: Woa... Now that I notice... this post is like 3 years old >.<