4 ms·
In theory that sounds nice and all, however in practice this leads to jitter, since the delta between the time the physics were done, and the time the frame is
by Mithaldu 10y ago
In theory that sounds nice and all, however in practice this leads to jitter, since the delta between the time the physics were done, and the time the frame is shown, keeps changing. In the worst case it skews slowly over time, leading to very ugly frame skips when the counter "flows over", despite the system running at full framerate.
In practice you must always have at least a smaller version of your physics engine, that your rendering loop needs to run before actually creating the frame, to do one of these two things:
- interpolate between the last and the previous physics state, accepting a constant additional latency between input and result
- extrapolate forward from the last physics state, accepting that what is displayed will occasionally be slightly wrong for a frame
Both of these come with their own problems, which may be bad enough to completely invalidate their use depending on whatever game type they're being used for.
So even if you decouple and parallelize your loops, you end up with 3 ways to handle the result, neither of them being without disadvantages. There are no silver bullets.
- ball_of_lint 10y agoWould there be any big issues to rounding the framerate to the nearest number evenly divisible by the physics rate on the fly? I'm meaning run it mostly like how he does but allow any framerate and eat the small changes in speed?
- jstimpfle 10y agoMonitor framerates are kinda "fixed". That is, there is no protocol to seamlessly change the framerate.
- wlesieutre 10y agoThough newer gaming screens are adding G-Sync (Nvidia) and FreeSync (AMD) to allow flexible monitor framerates. On a compatible GPU and screen you can display at whatever framerate you need, even a varying one, up to the maximum rate. The screen draws a new frame whenever you give it one. On that sort of hardware (and I'm assuming only in fullscreen mode) you should be able to match your render framerate to a multiple of your physics framerate. Whether you'd want to is arguable. If people noticed it they'd probably complain that maxing render at 140 Hz (assuming 20 Hz physics) on their 144 Hz screen is wasting their hardware. If you're doing it dynamically as physics perf varies up and down, the abrupt shifts in render framerate might be noticeable.
- Mithaldu 10y ago> physics perf varies up and down That sounds like you're advocating variable-length physics steps. Just a warning that that can be hilariously disastrous. Due to the way physics are simulated on computers, the simulation is never perfect, and the same timeframe simulated in 5 steps can give very different results than 1 step.
- FeepingCreature 10y agoCan't this be solved by keeping two copies of each value, and lerping between them based on the render timestep, essentially trading one frame of physics lag for zero jitter?
- Mithaldu 10y agoThat is what i described as the "interpolate" step. Anything doing that however will still need to have a rudimentary understanding of the physics, particularly since anything not moving in a straight line won't be lerped correctly.