6 ms·

Apparently one common fix for this according to some Reddit post is to use framecapping. It might be that i am too biased against delta timing in games (ie. usi

Apparently one common fix for this according to some Reddit post is to use framecapping. It might be that i am too biased against delta timing in games (ie. using the time delta between frames for animations) because i've seen way too many games break using it and is the reason i run any game older than ~7 years with framecapping enabled, but given the description on the site then i guess what is really happening is that since the game uses mostly baked lighting, they sample the environment lighting to apply to the entities and then -since the sampled positions, be it probes or lightmap lumels, are few and in fixed locations- they interpolate them as they entities move using the time delta between frames to make that interpolation look smooth. Then as the game runs in faster hardware, it ends up with smaller time deltas, which in turn breaks things because time deltas are evil :-P. Though that is obviously a guess (that this is what happens, not that time deltas are evil, that is fact :-P), though i've done something similar at the past for getting light on dynamic entities from a static environment, so some things did click.

colonwqbang 6y ago
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.
- 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.

colonwqbang 6y ago

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