Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I understand that using real time frame elapses (which should vary between 16-17ms on average) are provided by a lot of frameworks. GetTimeElapsedSinceLastFrame, and it gives you the wall clock time.

But should we use this information in basic physics simulation? It looks to me to be a bad idea.

Say there is a slight lag on the machine, for whatever reason (say a virus scanner starts up). The calculations all jump, and there is no need for this. Why not use a virtual second and ignore wall clock time? For gameplay on the level of Commander Keen, shouldn't you always use the virtual second and not real-time? (Besides stopwatch timing for race games) I don't see a need to use real time and not a fixed 16ms time step.

share|improve this question
How would you keep a virtual second from "jumping" any differently? – Byte56 Oct 10 '12 at 15:41
Here's a problem: you want your physics to be performed by watching the virtual time which you consider to be less prone to oscillations. Fine and dandy, but your update logic is not controlled by this virtual timer since the game process is slowed down by the virus scanner. Thus your virtual timer will also suffer from oscillations. If not, then your simulation will be frame-rate dependent, like in the first place. Some solutions suggest performing several physics cycles when possible, less when the fps is low. That's a hybrid approach and should lead to smoother simulation updates. – teodron Oct 10 '12 at 15:57
Please suggest a manner in which you would implement a "virtual timer" that is completely independent of the OS context switching between processes. Suggesting that each time step should be 16 ms does not take into account that the cycles per second is different on various configurations. – Justin Skiles Oct 10 '12 at 16:09
Maybe he talks about using a timer not based on the system time but on the frames of his game. For example simple count up all the frames. If the game lacks, everything would lack simultaneously. – danijar Oct 10 '12 at 16:25
@sharethis Using a frame-based approach to updating the game state would result in variable performance on different configurations even if they are all running 100% optimally because the amount of frames per second that can be executed is not constant. – Justin Skiles Oct 10 '12 at 17:28

What you mention is a well understood problem in general. The "virtual second" you mention is generall just thought of as a fixed time delta that is updated baed on an accumulator from wall time. The reason some developers use wall time directly is mostly ignorance on their part in most cases, and special circumstances in others.

The usual article to link folks to if you see them using wall time is the Glenn Fidler article Fix Your Timestep:

share|improve this answer

You seem to assume that most games aim for 60FPS, but actually it's much more varied than that. Console games tend to be either 60FPS or 30FPS. And games for PCs and other platforms tend to be wildly variable, though often related to the monitor refresh rate (which can be 60Hz, or 70, or 75, etc).

The reason you would want to tie game time to real time is because the player lives in real time. You don't want the gameplay to run at half the speed just because the player has selected high resolution graphics, for example. So when the game needs to update things, you want to update them proportional to the amount of real world time that has passed since the last time you updated them, or the player will notice odd behaviour.

But if your question is really about whether it's a good idea to let a variable visual frame rate affect a physics simulation, then the answer is that it usually isn't a good idea - but it's mostly trivial to work around, by picking an arbitrary timestep for physics and executing enough of those timesteps to keep up to date, based on the current real time, and maybe interpolating/extrapolating the rendering to smooth things out.

The reason this isn't done more widely is because it makes very little difference to most of the smaller games which don't perform any complex physics or where gameplay doesn't depend on the outcome of those physics.

There is plenty of discussion of this in other questions:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.