5 ms·

Unfortunately you cannot extend this approach much beyond this simple example if you are writing a physics simulation. There is no known closed form solution, f

Unfortunately you cannot extend this approach much beyond this simple example if you are writing a physics simulation. There is no known closed form solution, for example, for the famous three body problem, so a some sort of numerical integration is absolutely required. At that point, you should just decouple the numerical integration timestep from the monitor refresh rate, or mandate a refresh rate that will be acceptable to the player.

mort96 2y ago
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)
- gnuser 2y ago
  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 2y ago
    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 2y ago
      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 https://www.calculatorsoup.com/calculators/math/lcm.php
    - kibibu 2y ago
      > 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 2y ago
        That's why I wrote this part: > unless you do interpolation which is a different can of worms

mort96 2y ago

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)

gnuser 2y ago
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 2y ago
  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 2y ago
    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 https://www.calculatorsoup.com/calculators/math/lcm.php
  - kibibu 2y ago
    > 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 2y ago
      That's why I wrote this part: > unless you do interpolation which is a different can of worms