[SDL] SDL and timing - More examples?
david.olofson at reologica.se
Thu Mar 1 05:36:15 PST 2001
Yeah, I was thinking about hacking some simple example of real
time/multithreaded vs buffered systems and accurate timing... But what's the
problem with it, actually? (Coming from someone who spent countless hours
addressing that exact problem with a plugin API. ;-)
It's as simple as
1. Set up enough buffering to avoid underruns when trying to output
or interpolate data.
2. Put timestamps on all time critical events passed around.
3. Make sure you schedule the events long enough ahead, so that whoever
receives them actually get them *before* they're supposed to take
effect. This also applies if you have to deliver a continous stream
of data - "plan" far ahead enough not to have the *seding* thread
causing events to arrive late.
In more practical terms, for an audio system this would mean:
1. Set up enough buffering to avoid drop-outs.
2. Sound effects have to be stamped with the time when they're
supposed to be played. That's either "ASAP" (simple; ok if you have
very low latency audio) or "now + audio_buffer_play_time" (for
constant rather than random latency.)
3. Music may have to be decoded/mixed/whatever in a lower priority
"background" thead, and then passed to the real time mixer thread
(which also does the sound FX). Make sure you have enough buffers
queued up, so that the mixer thread doesn't have to skip the music
for some buffers occasionally.
In a video + control system scenario:
1. Run the control system far ahead enough that you have the data you
need to do any interpolation or whatever processing you need before
you can render a frame. (Usually, this is just a matter of running
the control system from within the main loop with a suitable delta
Decoupled control system/rendering? No, I generally don't approve
of that design because it solves *one* problem - control system
timing - while introducing several other problems, such as IPC sync
issues, poor timing accuracy (unsmooth animation) and overhead.
Sure, most of that can be solved nicely, but why bother? Yes, there
is one case: If you have a *really* heavy control system, running at
a much lower frame rate than the rendering. (Who does these days, at
least in an action game with constant, high frame rate animation?)
2. You *may* get smoother response if you timestamp user input events,
but in most cases, it's sufficient if you can just get all events
that came in since the last check right before processing each frame.
(Note: Just checking if the fire button is down is *not* ok! That'll
result in fast down/up transitions to be lost if the frame rate
should drop too much. Can be very annoying in games where you don't
want to sit and burn a truckload of ammo every time you press the
3. Well, this probably applies better to network play, where you have
to deal with network latency. However, in fast games, you probably
want to process events ASAP, even if that results in jerky timing,
at least if the average latency is way too high in the first place.
Processing is needed to clean the mess up a bit. (Movement
extrapolation and filtering + post event adjustments when the game
server finally tells the client what actually happened etc.)
In local gameplay, with insignificant latencies, and reasonable
frame rates, checking and processing input events once per frame is
Ok... Well, the *theory* is simple - I didn't say there's nothing much to it!
I'd like to hack an example that demonstrates how to solve the most common
problem with control system timing and rendering in a way that I find
sufficiently smooth, accurate and generic for serious games. At the same
time, it has to be simple enough for mortals to grasp - or 1) there's no
point in writing an example, and 2) I won't get it done! :-)
I have a "game" with two bouncing balls using a fully delta time based
engine, but 1) even the basic maths ain't all that simple and 2) the
ball/ball physics isn't correct. I'd rather fix it, or rip the broken parts
out before I release it.
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`--------------------------------------> david at linuxdj.com -'
More information about the SDL