SDL and timing - More examples?

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. :wink:

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! :slight_smile:

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