It's hard to make your game physics simulation numerically stable and consistent across a wide range of timesteps, unless you make it really complicated. Things like collision detection are often implemented in a way that only works for a certain range of object speeds and timesteps—and that's just one of many glitches that commonly result from running the physics simulation at an unintended frequency. Dividing things by unexpectedly tiny numbers can produce surprisingly big results.
The correct solution is to run the simulation on a different thread from the rendering, so that the simulation can be run at an appropriate frequency and the rendering can proceed at whatever framerate the user's hardware is capable of. The more commonly used "solution" is for the game to run the simulation and rendering on the same thread, and cap the framerate as a way to indirectly cap the simulation update frequency. Occasionally you find a game that merely assumes that the framerate won't go over 60Hz, and if your monitor is faster, the game itself runs in fast-forward.
No, this is not how it's mostly done correctly in practice. Most physics calculations are run at a predetermined frequency, and then the appropriate amount of iterations are done before drawing each frame (it may be zero). And then one can use the reminder of the delta to interpolate positions if needed.
I think very few games run the physics in a different thread, that sounds like asking for trouble.
> No, this is not how it's mostly done correctly in practice.
I don't believe anyone was asserting that how it's usually done in practice is the right way to do it. Developers obviously have a strong preference for easy over correct and flexible.
What you describe is a reasonable compromise for developers who are afraid of multithreading even with a straightforward producer-consumer data flow. It comes with its own complications, like having to buffer input events along with their timestamps to apply them during the right catch-up iteration of the simulation.
Usually a constant time step is used, and you throttle the rate at which you run physics ticks to make that match wall clock time. It’s common for game physics engines to also run iterative integrators for a fixed number of steps per tick instead of to convergence, which reduces variation in work per tick. If the system can’t keep up, you start dropping physics frames.
You keep animation smooth by decoupling it from physics; the output of your physics engine will generally include at least linear and angular velocities you can use for interpolation. This kind of thing is necessary anyway if you’re running your physics simulation on a server and have to communicate to the renderer over the network.
With the simulation as a separate thread, and presumably with a well defined interface, a less intensive (and lower TPS) simulation could be switched out at lower performance levels.
I think you completely misunderstood that sentence. Let's try again:
> The correct solution is to run the simulation on a different thread from the rendering, so that the simulation can be run at an appropriate frequency and the rendering can proceed at whatever framerate the user's hardware is capable of.
The "running in another thread" is a way to enable running the simulation at a fixed frequency where it will produce "correct" results, while not imposing the same constraints on the rest of the game engine that are not as sensitive to timestep issues. I never said that moving the simulation to a thread of its own is the entire solution itself, and "increasing performance" isn't the goal or result.
The correct solution is to run the simulation on a different thread from the rendering, so that the simulation can be run at an appropriate frequency and the rendering can proceed at whatever framerate the user's hardware is capable of. The more commonly used "solution" is for the game to run the simulation and rendering on the same thread, and cap the framerate as a way to indirectly cap the simulation update frequency. Occasionally you find a game that merely assumes that the framerate won't go over 60Hz, and if your monitor is faster, the game itself runs in fast-forward.