4 ms·

Just out of curiosity, what is the problem with delta timing and what is the alternative?

wtallis 6y ago
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.
- hu3 6y ago
  Interesting but: 1) How do you deal with hardware that can't run the simulation at the appropriate frequency? 2) How do you keep simulation and animation smooth and linear over time when facing processing oscilations if not by using time deltas? 3) Is ther a graphics/processing demanding game that doesn't use time delta?
  - mjevans 6y ago
    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.
  - johncolanduoni 6y ago
    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.
- jfkebwjsbx 6y ago
  Running in another thread does not make it correct, it only increases performance.
  - wtallis 6y ago
    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.
    - jfkebwjsbx 6y ago
      Ignoring your condescending tone, there is no need for another thread to "enable" running the simulation at a fixed frequency. In fact, a myriad of games (and other kinds of simulations) have been doing exactly that for a very long time.
- matsemann 6y ago
  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.
  - wtallis 6y ago
    > 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.
badsectoracula 6y ago
Numerical instability introduced by very small and very big and always varying delta values. At its core it is something like running pos += speed*delta for every frame with delta having varying precision depending on what is rendered on the current frame. The solution is to change this to run pos += speed at fixed intervals while still rendering every frame. This will fix any issues with delta timing, but it will force your animations to run at the interval you choose regardless of framerate. If you use something like 60Hz however it will be fine for the vast majority of users since 60Hz screens are everywhere, however you'd still be wasting time rendering unnecessary frames. One solution for this is to cap the framerate (vsync at 60Hz will do that but not everyone likes vsync for unrelated reasons) but a better solution is to interpolate the previous and current states using the interval between updates when rendering, so something like visible_pos = prev_pos*(1.0-inbetween) + pos*inbetween with inbetween being calculated using something like inbetween = (now - last_time)/(1000.0/interval) (last_time becomes now in the next update - ie. when pos += speed is called) The drawback with this is that in the worst case (inbetween=0) the visible output is one frame behind, though without any form of framecapping (including no vsync) it this should rarely be the case and with 60Hz intervals it shouldn't be visible even on 120Hz+ monitors. But if you want to avoid this you can have some systems use the current position instead of interpolating them, e.g. have the camera's direction in first person games bypass the interpolation so that when the user moves the mouse they get the most instant feedback. Personally i've used this approach on my last engine and it has buttery smooth and instant response without any perceivable lag or issues even on a 120Hz CRT monitor (pretty much all modern flat panel PC monitors have response time issues that can hide frame latency issues, but nothing stays hidden on a fast CRT :-P).
- dcow 6y ago
  Could you just allow variable delta between two bounds that you control like 1fps and 600fps and make sure that computations work at both capped extremes to avoid degenerate behavior? Or are there downsides to that approach as well?
  - badsectoracula 6y ago
    Well, considering i've seen several games break even with 120fps (they were probably never tested at such high framerates), i'd say there are. Though the lower the cap, the less likely you are to see issues in such games (probably because the games were tested with those framerates). But the tiny deltas are one issue. Another is that you get variable deltas and they can go from big to small (even capped) from one frame to another and this can still introduce numerical instability and harder to spot heisenbugs. It might sound like a PITA to keep the previous state around but you really only need it for things that can't be calculated on the fly (e.g. position that can arbitrarily change) but others can be calculated (e.g. particles) and in the long term you are making a more robust system and saving yourself from having to chase after weird bugs. By having everything run at fixed updates you know that once you see something working, it'll keep working regardless of the framerate.

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.

hu3 6y ago
Interesting but: 1) How do you deal with hardware that can't run the simulation at the appropriate frequency? 2) How do you keep simulation and animation smooth and linear over time when facing processing oscilations if not by using time deltas? 3) Is ther a graphics/processing demanding game that doesn't use time delta?
- mjevans 6y ago
  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.
- johncolanduoni 6y ago
  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.
jfkebwjsbx 6y ago
Running in another thread does not make it correct, it only increases performance.
- wtallis 6y ago
  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.
  - jfkebwjsbx 6y ago
    Ignoring your condescending tone, there is no need for another thread to "enable" running the simulation at a fixed frequency. In fact, a myriad of games (and other kinds of simulations) have been doing exactly that for a very long time.
matsemann 6y ago
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.
- wtallis 6y ago
  > 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.

badsectoracula 6y ago

Numerical instability introduced by very small and very big and always varying delta values. At its core it is something like running pos += speed*delta for every frame with delta having varying precision depending on what is rendered on the current frame. The solution is to change this to run pos += speed at fixed intervals while still rendering every frame. This will fix any issues with delta timing, but it will force your animations to run at the interval you choose regardless of framerate. If you use something like 60Hz however it will be fine for the vast majority of users since 60Hz screens are everywhere, however you'd still be wasting time rendering unnecessary frames. One solution for this is to cap the framerate (vsync at 60Hz will do that but not everyone likes vsync for unrelated reasons) but a better solution is to interpolate the previous and current states using the interval between updates when rendering, so something like visible_pos = prev_pos*(1.0-inbetween) + pos*inbetween with inbetween being calculated using something like inbetween = (now - last_time)/(1000.0/interval) (last_time becomes now in the next update - ie. when pos += speed is called) The drawback with this is that in the worst case (inbetween=0) the visible output is one frame behind, though without any form of framecapping (including no vsync) it this should rarely be the case and with 60Hz intervals it shouldn't be visible even on 120Hz+ monitors. But if you want to avoid this you can have some systems use the current position instead of interpolating them, e.g. have the camera's direction in first person games bypass the interpolation so that when the user moves the mouse they get the most instant feedback. Personally i've used this approach on my last engine and it has buttery smooth and instant response without any perceivable lag or issues even on a 120Hz CRT monitor (pretty much all modern flat panel PC monitors have response time issues that can hide frame latency issues, but nothing stays hidden on a fast CRT :-P).

dcow 6y ago
Could you just allow variable delta between two bounds that you control like 1fps and 600fps and make sure that computations work at both capped extremes to avoid degenerate behavior? Or are there downsides to that approach as well?
- badsectoracula 6y ago
  Well, considering i've seen several games break even with 120fps (they were probably never tested at such high framerates), i'd say there are. Though the lower the cap, the less likely you are to see issues in such games (probably because the games were tested with those framerates). But the tiny deltas are one issue. Another is that you get variable deltas and they can go from big to small (even capped) from one frame to another and this can still introduce numerical instability and harder to spot heisenbugs. It might sound like a PITA to keep the previous state around but you really only need it for things that can't be calculated on the fly (e.g. position that can arbitrarily change) but others can be calculated (e.g. particles) and in the long term you are making a more robust system and saving yourself from having to chase after weird bugs. By having everything run at fixed updates you know that once you see something working, it'll keep working regardless of the framerate.