[SDL] Blitting / event handling with multiple threads

Christian Morgner christian.morgner at postamt.cs.uni-dortmund.de
Mon Jan 31 13:14:59 PST 2005


Hi,

> Threading is not a magic performance booster unless you have a
> multiple processor system (which I doubt your customers/target
> audience have). Also, because you must synchronize computations
> between e.g. drawing and physics updating, you get a lot of extra
> work, only for a gain in the similarity between your program and how
> you think of your program (not a bad gain but in this case the
> trade-off between engineering effort and model-resemblance is really
> not worth it, trust me) not to mention the problem of not being able
> to call library functions in threads different from the main thread,
> in general.
>
> There is nothing that keeps you from doing several game-object updates
> inbetween SDL_Flip's, if that is a limiting factor, or not drawing all
> object (for example only drawing the ones that have actually moved!).

Ok, then the best is to call each object's draw() method in the main thread 
along with the event handling, and create a separate thread for the actual 
game logic?

I already have a working beta version with about 60% of the functionality of 
the original game, but it was just too slow, running in a single thread with 
60 updates / seconds.

> Could you describe your game a little more specifically? What are the
> rules? Is it scrolling? Etc. etc.

Its a real-time strategy game called "Dune II", and I'm writing a clone of it 
from scratch. I already decoded all the graphics, animation and font formats 
from the original game and can convert it to SDL_Surfaces on loading, but the 
drawing of 100+ surfaces plus the game logic was too slow.
There are different types of objects: sprites like vehicles, soliders, 
bullets, rockets and sandworms :), and map objects like structures (that have 
an animation, too), sand, concrete, rock. In the game, object AI is 
controlled by an object-internal script language, each object needs a 
path-finding algorithm to avoid collisions with other objects. Objects scan 
the area around them. There is a map that has 64x64 tiles and the player's 
view is 15x10. The method of updating and drawing everything in one thread is 
just too slow.

>
> If you have followed the usual tricks-of-the-trade from the SDL-faq
> (SDL_DisplayFormat eg.), then continue to read.
>
> My general advice is pick up some algorithms book and/or real time
> computer graphics book to get ideas on how to improve performance. An
> excellent book on the real time rendering subject is

There is no need for real-time rendering, just blitting the right part of the 
surface of the sprite, or blitting a fire animation / smoke animation, do 
some palette animation and things like that, but about 100 objects that need 
to be drawn, interact with each other, find a path on the map and so on is 
just too slow with 60 fps, so I think separating the update() methods from 
drawing and event handling should be working.

Thank you,
-Christian




More information about the SDL mailing list