The built-in time-stepping support for the upcoming release of SmartMS got an overhaul in the form of a now frame-rate oriented Game View component, and a simulation-oriented TMetronome time-stepper.
This article quickly discusses the theory, changes, and gives an introduction for use in games and simulations.
Time-Stepping in Simulated Worlds
Time stepping in simulated worlds is a general problem not restricted to games.
Basically, you have to deal with screen updates that take a variable amount of times, not just because what you need to draw (render) on the screen can vary (which would be bad enough), but because the environment introduces latencies (other applications taking CPU time, network lag, storage access times, etc.).
While you sometimes want to render at a high frame-rate, outside of benchmarks, there is no point rendering more frames than the screen can display, as it’ll only waste energy.
On the simulation side, you usually want some reproduce-ability (if only for debugging and testing), and you want to ensure that while the visuals can depend on the capability of the hardware you’re running on, the simulation shouldn’t depend on the hardware, which means fixed time-steps.
So the general problem is to adapt a variable time-step problem (rendering) with desired synchronization (with screen refresh) and a simulation with fixed time-steps.
A good discussion of the pros and cons can be found in Fixed time step vs Variable time step.
