[SDL] SDL_WaitEventTimeout

Bob Pendleton bob at pendleton.com
Sun Nov 2 11:01:01 PST 2003

On Sat, 2003-11-01 at 13:12, tfolzdon at student.umass.edu wrote:
> Bob Pendleton pointed out a bug in my sample code.  Should have been:
> (in pseudocode)
> while(!done){
> 	gotone = SDL_WaitEventTimeout(e, nextick - SDL_GetTicks());
> 	if(gotone){
> 		execute_user_input(e);
> 	}
> 	if((time = SDL_GetTicks()) >= nextick){
> 		if(time >= nextick + ticklen)
> 			nextick = time + ticklen;      
> 		else
> 			nextick += TICKLEN;
> 		do_once_per_tick_stuff();
> 	}
> }

This correction only corrects a small part of what I consider to be
wrong with your code. The implementation of your version of
waiteventtimeout had serious problems and leads you to making the kind
of error that was in your original code.

Take a look at this bit of psuedocode as an alternative to what you have

nextTick = SDL_GetTicks() + ticklen;
while (!done)
	while (SDL_PollEvent(e))


	while (ticklen > SDL_GetTicks())
		SDL_Delay(5); // Delays an *average* of 5 milliseconds

	nextTick += ticklen;

It does pretty much what your loop does. (To me it is a lot easier to
read, YMMV :-) It processes *all* pending events before updating. That
way all user input is always reflected in the next update. Then it
performs an update. Only then does it throttle the frame rate by

Always processing all user input before an update is a requirement for
getting a good responsive feel in the game. User input handling and
updating usually take a variable amount of time. This loop adjusts to
that while still giving you an average frame rate near your ideal frame
rate. The thing is that you might get caught waiting for a frame to flip
or waiting while the OS steals the CPU for other operations. So, if you
don't process an event right now it may be as much as a few hundred
milliseconds before you get a chance to process it and that amount of
time is visible to humans.

This is *close* to the way I like to code, but I still am not completely
happy with it. Because you don't really know when you are going to get
the CPU you can't count on doing things on a fixed time basis. What
happens if my loop gets blocked for a few ticklens of time? The loop
will race to catch up causing a visible glitch in the animation. IMHOP
'tis best to do everything based on elapsed time and throttle when the
frames are coming to fast to be visible.

For a better description of what I mean take a look at my articles on
animation with SDL at:


I believe these are also linked to from libsdl.org.

		Bob Pendleton

+ Bob Pendleton: writer and programmer. +
+ email: Bob at Pendleton.com              +
+ web:   www.GameProgrammer.com         +

More information about the SDL mailing list