[mort96]

You can do that, but it has serious drawbacks. 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. This is appropriate for certain kinds of very realistic physics sim style games, but usually undesirable due to performance.

* Run physics at some fixed, sane rate (somewhere between 20 and 100 Hz probably), and then do rendering separately, interpolating between positions for refresh rates higher than the physics tick rate. This can be hard to make feel good on refresh rates which aren't clean multiples or divisors of the tick rate, but ensures that physics behaves identically independent of frame rate.

* Couple rendering and physics and run at a fixed frame rate (60 FPS). This will work okay for many players but a whole lot of people will be angry at you that your game is choppy on their fancy high refresh monitor, and if you don't change monitor mode to change the monitor's refresh rate, a 144Hz screen will sometimes refresh twice and sometimes thrice per game frame, meaning nothing will ever seem smooth even by 60 FPS standards.

* Couple physics and frame rate but allow the delta time to vary (maybe running physics 2 or 3 times per frame if the frame rate is really low). I'd say this produces the best results for any given refresh rate, and it's relatively simple to implement, but it causes physics to behave slightly differently with different frame rates, and it's prone to bugs like the one discussed in this article.

It's not an easy decision, there is no good rule of thumb. I tend to prefer the last option I listed for my games, but I'm aware that it has drawbacks. But "just decouple physics from rendering" is certainly not the straightforward rule of thumb you seem to suggest it is. (EDIT since this post seemed more negative than I meant: running at a fixed time step is a good solution and very appropriate for many games, I'm not saying your suggestion is bad)

[markisus]

Thanks for bringing up the intricacies involved. I shouldn’t have used the word “just” as it implies that the solution is easy.

[nextaccountic]

> 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.

[mort96]

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

[nextaccountic]

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

[gnuser]

In godot (compile main daily) I am running 120 tick rate but have found some interesting optimizations happen there and above (240) and am seriously temped to just make 240 my default (but I need to do more server load tests as I’m planning to scale)

[mort96]

240Hz has issues too though, it means that there's on average 1.66 physics ticks per screen refresh on a 144Hz screen. In practice that means that an object moving at, say, 0.1 meter per tick will have moved 0.1 meters in some frames and 0.2 meters in other frames, which leads to choppy animation. That's why I mentioned tick rates in the kilohertz; sometimes having 10 ticks between frames and sometimes 11 ticks isn't a big deal, but sometimes having 2 and sometimes 1 is noticeable (and obviously if some frames have 1 tick and some have 0 ticks between them, that's a disaster (unless you do interpolation which is a different can of worms)).

Now running physics at 240Hz or even 120Hz might still be the right choice for your game, especially when taking into account human factors and time constraints, it's just not a panacea

[schiffern]

For 144 and 240 Hz, the LCM (least common multiple) would be 720 Hz. At 144 Hz that's 5 ticks per frame, and at 240 Hz it's 3 per frame.

https://www.calculatorsoup.com/calculators/math/lcm.php

[kibibu]

> will have moved 0.1 meters in some frames and 0.2 meters in other frames

Not if you interpolate based on previous position. This means you accept up to 16ms display latency, but the trade off is smooth motion.

[mort96]

That's why I wrote this part:

> unless you do interpolation which is a different can of worms