[SDL] Blitting / event handling with multiple threads

Alan Wolfe atrix2 at cox.net
Mon Jan 31 13:27:50 PST 2005

Hi Christian,

You say it updated 60 times a second? IE your framerate was 60 times a

If so id say the "issue" is that you have vsync enabled, where it
synchronizes the actual drawing with the verticle resync interupt of your
monitor to reduce tearing.

my appologies if you already know about vsync but if you dont, vsync doesnt
actualy "slow down" your game at all.  it limits your FPS to 60, but is no
indication of the speed of your code, you could do twice as much logic lets
say and still be at the 60 fps.

PS Dune II rocked so hard, be sure and anounce here when you have a playable
version please!!

::makes a wall of sonic tanks:: muhaha! (:

----- Original Message ----- 
From: "Christian Morgner" <christian.morgner at postamt.cs.uni-dortmund.de>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<sdl at libsdl.org>
Sent: Monday, January 31, 2005 1:14 PM
Subject: Re: [SDL] Blitting / event handling with multiple threads

> 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
> 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
> the original game, but it was just too slow, running in a single thread
> 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
> from scratch. I already decoded all the graphics, animation and font
> from the original game and can convert it to SDL_Surfaces on loading, but
> 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
> 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
> 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
> 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
> surface of the sprite, or blitting a fire animation / smoke animation, do
> some palette animation and things like that, but about 100 objects that
> 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
> _______________________________________________
> SDL mailing list
> SDL at libsdl.org
> http://www.libsdl.org/mailman/listinfo/sdl

More information about the SDL mailing list