[SDL] SDL and timing - More examples?

[David Olofson]

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.


//David

.- 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 -'