[SDL] Blitting / event handling with multiple threads
bob at pendleton.com
Mon Jan 31 13:45:40 PST 2005
On Mon, 2005-01-31 at 13:27 -0800, Alan Wolfe wrote:
> 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!!
You just asked him to do something that is illegal in most countries.
Illegal to distribute it, and illegal to receive it. And you did it in
> ::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
> SDL mailing list
> SDL at libsdl.org
More information about the SDL