[tlarkworthy]

you are still doing it wrong. dt should not be affected by framerate. http://gafferongames.com/game-physics/fix-your-timestep/

use an accumulator to have a fixed dt no matter the framerate. With a variable step size you risk all kinds of weird bugs linked to the hard to debug rendering context. The size of dt should be consider a system parameter, tuned for your game and fixed in concrete.

[Jare]

This problem involves performance, precision, code stability and player perception, so there are no hard and fast rules applicable everywhere, and certainly do not need always to be fixed in concrete. A game can mix variable dt and fixed dt in different subsystems (render, logic, physics, user input, network, ...).

I have even managed to dynamically change these settings and parameters on the fly: which subsystems use which method, the lower and upper limit for variable dt, number of iterations per render frame, and even value to use for fixed dt, all adjusting depending on framerate and state of the game.

A classic example of this is, during a big explosion you may need maximum precision on physics (fixed dt with low value), can afford variable dt on behaviour and interface (since stuff is just blowing up in the air), and can benefit from a low maximum dt that causes a bit of slow-motion (John Woo style!).

When you're doing multiplayer there's a lot less you can afford to change, because you need to keep timing sane and synced across clients & server. Everything depends on the game, the engine, the platform, and the dynamics of what the player is seeing.

[charliesome]

It may still be wrong, but the point is that it's less wrong and it's not much extra effort.

[rorrr]

So what happens when the OS doesn't return to your process in dt time?

The whole point of dt is to deal with variable framerate.

[paulhodge]

When your game does regain control, it can run the simulation for N steps (however many it usually does for the given dt), then finally render the scene using the latest state. (so the game will appear to pause, then skip ahead). Or it can try to play catch-up, it does 1 tick and render at a time, but with a reduced delay between frames until it's "caught up". (so the game will pause, then appear fast-forwarded for a bit).

Either way Tlark is right, you really don't want the game logic to be affected by framerate.

[anonymous]

Then the game runs in slow motion. There's not much you can do on a slow system.

Or if you mean that you may be forced to draw at (for instance) 55fps, then the solution is to precalculate the next physics frame and linearly interpolate between the previous and next frame when drawing.