views:

92

answers:

1

What is a good processing sequence and/or threading model to use to give a user impression of well synchronised physics model, audio, video, sound and input in an application, assuming the application prepares no "predictive" frames or sound?

EDIT

My question assumes no "networked game" concept, just a standalone machine.

+1  A: 

Broad question.

I'm assuming a game context. What seems to be done more or less universally is to synchronize on frame rendering. Here's roughly what happens:

  • Inputs are grabbed and evaluated, responses (AI and such) computed. This may set new physics processes in motion.
  • If an event starts that is accompanied by a sound, that sound is started up. It runs more or less autonomously from that point on, until it completes, independently of frame processing (which is where we are)
  • The physics model is updated. In most cases this will be something pretty simple like calculating a new position from previous position and velocity. The amount to extrapolate by depends on the amount of time that passed since the last frame (though this may be averaged rather than re-computed for every frame)
  • From the updated physics model, the visual model is updated.
  • The graphics engine gets to display a new scene (frame) from the updated model.
  • Repeat as soon as done.
Carl Smotricz
The way I read that, sounds like some extrapolation as-a-function-of-time is required (to reconcile current time when new frame render starts, to game time) but not necessarily "predictive" extrapolation.
martinr
Well, you can do either but retroactive extrapolation is both easier and more exact because you can know exactly how much time passed. Also, at decent frame rates (above, say, 20 FPS) no human can tell the difference.
Carl Smotricz
If your frame times are variable (i.e., if you generate frames as fast as possible), make a debug facility to log the actual frame times and the inputs. Then make a playback mode that uses the logged times and inputs instead of the real clock and live inputs. That'll give good reproducibility for debugging. (Seed your random-number generator, too.)
Adrian McCarthy