[SDL] SDL_WaitEventTimeout

David Olofson david at olofson.net
Sat Nov 1 19:05:00 PST 2003


On Saturday 01 November 2003 20.12, tfolzdon at student.umass.edu wrote:
[...]
>   Now, actually, my tetris *does* need to draw every 50ms, because
> it changes the colors of everything every 50ms (red=sin(t),
> green=sin(t+2pi/3), blue=sin(t+4pi/3)).  A framerate of 20fps is
> sufficient for the drawing, but apparently not for my users. 
> Should I increase the framerate, which will only increase CPU
> usage?

So why don't you just handle the color changes like any other game 
logic event, so that they cause video updates? You can only have one 
rendering frame rate, but it's not *required* to be constant or 
locked to anything in particular. Just update whenever you need to - 
which may include directly after receiving an input event.


[...]
>   As I understand it, libSDL keeps a thread for input of it's own.

On most platforms, yes, AFAIK.


> So, I would be interposing a thread between libSDL's event thread
> and my application's thread that actually does stuff, a gratuitous
> waste of system resources.

Yeah - but SDL doesn't timestamp events, so if you need event input 
timing to be more accurate than the logic and/or rendering frame rate 
of your game, this is the only way. If you poll the event queue in 
the same thread that does the rendering, your input timeline will get 
"holes" of the size it takes to render one frame.

However, in most cases, this is not an issue. If the rendering frame 
rate is so low that it could interferes with input, the game is 
usually not playable anyway.


>   Another problem with multithreading is correctness.

Well, yeah - if you want your events timestamped, you have to pass 
them to your main thread through a lock-free FIFO or something like 
that... Quite trivial, actually. Either way, it's still something you 
most probably won't need to do.


> In Quake,
> drawing is done as quickly as possible, churning out frames.

Except that the monitor refresh rate should limit the maximum frame 
rate on proper setups.


> The
> logic is rather independent of the drawing, doing AI here and
> noting that an explosion occurs over there, and informing the
> drawing routine thereof.  And input happens when it happens.  I
> don't know if ID Software actually implemented Quake as a
> multithreaded application, in fact, as it runs under MacOS, I
> rather doubt that Quake is multithreaded.

I don't know if it has separate logic and rendering threads, but I 
strongly doubt it. If logic ran in a separate thread, the venom gun 
in RTCW (which uses the Q3A engine) wouldn't lose fire rate if the 
rendering frame rate drops too low - but that's exactly what happens. 
(That is, RTCW doesn't even handle progress of time properly in such 
cases. Logic events are lost if the frame rate is too low.)


> But it would make sense
> to multithread it.

Not really; at least not considering what this thread is about. The 
venom gun problem in RTCW is a bug, and fixing it wouldn't require a 
separate logic thread.

Kobo Deluxe uses only one thread for logic and rendering, and it still 
plays correctly down to 1 Hz - though the game is obviously 
unplayable at that frame rate, because you can't see what's going on, 
and because input events are quantized to 1 Hz.


> However, input, logic and drawing are not
> asynchronous in Tetris.  Nor are they asynchronous in Space
> Invaders, PacMan, or a variety of other types of program.

Nope. And there's no need for that, as those games just maintain a 
sufficient frame rate to keep animation smoothness and input latency 
at acceptable levels. You can do that by either updating at a 
sufficient rate (could be fixed, or the highest possible rendering 
rate), or by updating whenever something needs updating.


>   Which is why I think such an function is necessary to at least my
> game's logic, and why I think most APIs (UNIX, MacOS, 'doze, etc.)
> include such a call.

I think the "proper" way would be to go completely event driven, and 
just use SDL_WaitEvent(). Use timers to generate events for 
"spontaneous" things like color cycling, animations and stuff. Using 
timeouts to actually generate timing tends to be hairy, flaky and 
inaccurate no matter how you implement it.


//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