[SDL] Too Fast!

David Olofson david at olofson.net
Thu Aug 5 12:29:26 PDT 2004


On Thursday 05 August 2004 18.27, Romulo Gnomo wrote:
> I´m creating a simple engine that uses SDL, but I
> don´t know how to fix the problem of the things
> working too fast. I don´t know how to control
> framerate so things aways go in diversified speed and
> I don´t want it. How can I adjust the speed of the
> engine? I mean, so people (and me) will be able to run
> my simple demo´s/test progs at the speed I wanted it
> to show at the refresh rate they want. Is that a
> simple way of doing it?

You *can* restrict the rendering (and logic) frame rate to some 
arbitrary value, but I'd recommend against it for three reasons:

	1) It eliminates all chances of utilizing "spare"
	   rendering power for smoother animation.

	2) The resulting frame rate is likely to interfere
	   with the refresh rate of the display, which
	   cannot safely or reliably be changed.

	3) It doesn't solve the situation where rendering
	   is too slow, so your game logic may run too
	   slow on slower machines, unless you deal with
	   that specifically.

The best and most robust solution is to separate the game logic from 
the rendering frame rate. There are some different approaches to 
this, including:

	* Fixed logic frame rate with timer driven thread. (Game
	  logic is handled in a separate thread that is driven at
	  a fixed rate - say 100 Hz - by a timer of some sort.)
		+ Simple - at least in theory.
		+ Easy to design exact (repeatable) game logic.
		+ Fixed frame rate ==> simple and robust game logic.
		- Depends totally on OS scheduling accuracy and
		  granularity for smooth animation.
		- Threading issues complicates the code.
		- Threading overhead. (Virtually zero on some
		  platforms, though.)
		- Needs interpolation for smooth animation at all
		  rendering frame rates.
		- Interpolation is hard to get right, since there
		  is no hard synchronization between the logic and
		  rendering threads.

	* Fixed logic frame rate with frameskipping and/or
	  interpolation. (Game logic runs in the rendering thread,
	  but is throttled so that it runs at the correct average
	  frame rate.)
		+ Fixed frame rate ==> simple and robust game logic.
		+ Easy to design exact (repeatable) game logic.
		+ No multithreading complexity
		+ Interpolation is easy to implement, since there
		  are no asyncronous buffering issues.
		+ A very high logic frame rate (say 1 kHz) is an
		  easy hack if you want to avoid interpolation.
		- Needs interpolation or very high logic frame rates
		  for smooth animation at all rendering frame rates.

	* Time based logic. (Logic frame rate == rendering frame
	  rate, but speed, acceleration etc is scaled based on the
	  delta times between frames.)
		+ Accurate positions and smooth animation,
		  regardless of frame rate.
		+ No need for interpolation for perfectly smooth
		  (even sub-pixel accurate) rendering.
		- Exact/repeatable game logic is hard to implement.
		- Special measures must be taken to ensure that
		  collision detection works properly at low frame
		  rates.
		- Game logic is complicated by extra math for the
		  time scaling.


(Note: My personal favvourite for 2D action games is the second one; 
fixed logic frame rate + interpolation. That's what I use in Kobo 
Deluxe and Fixed Rate Pig, both found on my site.)


> How can it be incorporated
> with a graphic engine?

That depends on how you deal with the game logic timing. It's rather 
trivial as long as you keep the game logic in the same thread as the 
rendering engine. It gets a bit trickier with interpolation (need to 
buffer some old coordinates for each object and do the actual 
interpolation to get the graphics coordinates for each frame), and 
perhaps even worse with a multithreaded approach, due to the sync 
issues. (Can't just share variables. At best, you'll get occasional 
jittering.)


> Is it a good idea for an engine
> to have something like a "sprite warehouse" where all
> the sprites are putted in?

Why not? I have something like that in Kobo Deluxe and Fixed Rate Pig, 
and it's turned out to be rather handy when dealing with groups of 
related sprite images, animations and stuff. (Integer indices rather 
than pointers, so all you need is start and count.)

Anyway, it depends on the rest of your design. For example, a script 
driven engine wouldn't really need any centralized bank like that, as 
you can just manage images on a per-object basis, in whatever way 
suits each object. High level languages usually do a good job of 
making that easy anyway, so why second guess your scripting engine?


> Thanks alot! I need to say
> this timer thing will need to work with the sound
> system too latter.

Yeah, another tricky detail... The easy way is to just send 
asynchronous messages from the game logic to the sound engine 
(perhaps using a lock-free FIFO, as I do in Kobo Deluxe) - but that 
obviously means that sound timing is quantized to the physical logic 
frame rate (same as the rendering frame rate unless you have a 
separate logic thread) and/or audio buffer size.

In recent (not officially released) versions of Kobo Deluxe, I've 
introduced a timestamped interface that keeps a "constant" latency, 
rather than the random jittering and quantization effects of previous 
versions. Very simple stuff in theory, but things are complicated by 
the timing jitter caused by OS scheduling granularity, rendering time 
fluctuations and stuff. That's handled by a slowly decreasing time 
offset that's adjusted slightly whenever the engine realizes the 
delay is smaller than the minimal latency.


> Do you think I´m the right path for etting anything
> done? 

The single most important factor is motivation; if you really *want* 
to get something done, you will, one way or another. Anyway, your 
thinking makes sense, so chances are good, I think. :-)


>  Sometimes I think it is better to plan
> everything before start, than making things work and
> slowly improve them.
> What do you think about it? The Design of engines?

Well, there are different "scools". Some say you should definitely 
design *everything* before coding anything, whereas others say you 
should basically start coding as soon as you know the set of problems 
to solve.

Personally, I think the former approach is most suitable for low level 
languages (C or asm) and/or environments or situations where 
incremental coding and testing is hard. It may also have some 
relevance to high level design (APIs and stuff) in large projects 
with many developers. As for my own personal and work related 
projects, I've realized that I've drifted more and more towards a way 
of working that resembles Extreme Programming a great deal.


> Any
> good tip about a book or online material?

There are some SDL examples, tutorials and articles around. You can 
find some of them on the SDL site, but there's probably more out 
there.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---





More information about the SDL mailing list