| > You can: > * Run physics at such a high rate that sampling it at 30 or 60 or 144 or 260 hertz is fine, like running physics at 1kHz. > (...) > Couple rendering and physics and run at a fixed frame rate (60 FPS) Both are sensible, but you can do better: First you can detect the monitor framerate and do a benchmark to get which framerate the computer can comfortably run the game (at not too much CPU utilization), and take the minimum from those two values. That's a good way to gauge a baseline. The only problem is that the simulation will not be deterministic across two different computers (but there are many other sources of nondeterminism, and many games are okay with that) Then another further issue is that if you run physics at exactly the same frame rate as the monitor, you might sometimes run two physics steps during a frame, or no physics step during a given frame, which causes staggering. To solve that, if your baseline ends up being your framerate, you then run the simulation at a few Hz higher than that (Bevy for example defaults to 64Hz [0], imagining that 60Hz monitors are still common) [0] https://docs.rs/bevy/0.13.2/bevy/time/struct.Fixed.html > The default timestep() is 64 hertz, or 15625 microseconds. This value was chosen because using 60 hertz has the potential for a pathological interaction with the monitor refresh rate where the game alternates between running two fixed timesteps and zero fixed timesteps per frame (for example when running two fixed timesteps takes longer than a frame). Additionally, the value is a power of two which losslessly converts into f32 and f64. |