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 time argument.) 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 button...) 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 usually sufficient.
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 -’