> * 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)
> 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.
Wait but when you run physics at 64Hz for a 60Hz refresh rate, you'll still see some refreshes with 1 step and some with 2, which means you need some interpolation scheme if you wanna avoid a stuttering mess still. You should have some form of synchronisation which ensures that exactly one physics step happens between each frame that's displayed to the user
You always need such interpolation nonetheless, because the physics timestep is fixed but your FPS will not always be 60 (that is, you may have slowdowns that lower your FPS temporarily)
Running two physics steps in the same frame isn't a problem (besides consuming CPU pointlessly), the problem is when you run no physics step between one frame and another
> * 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.