TL;DR games are still doing the idiotic variable, rendering-time-dependent ticrate rather than a fixed ticrate for physics and skipping rendering of some ticks when gpu can't keep up. *sigh* And their analysis of the solution is all wrong.https://twitter.com/j3ffdr/status/1024330252816924672 …
-
-
This won't solve the problem (you can't detect the "missed" frame, is the issue). And anyway if skip a frame you'll have a different kind of hitch from that.
-
Hmm... My last two 3D engines ran everything on the game-logic/... side of things at 25Hz (older with 100Hz for physics), though rendering and player movement were variable. Timing was purely accumulation rather than prediction though (the "stutter" seems to imply prediction).
-
Fixed rate physics sims or entire game engines are all well and good if you want em, but none of this addresses the frame stutter problem in the article. Not an issue of prediction, but of not knowing when your frame has actually posted onscreen
-
As a result, there is no policy of timing you can undertake to always match the screen updates. It's a driver & OS issue and not one gamedevs can solve completely
-
It seems you can solve it within some degree of quality by using whatever imprecise timing information the buggy drivers give you and feeding it into a PLL to sync your idea of time to it, skipping rendering a frame if you fall behind. May skip "wrong" frame in that case...
-
...but you'll avoid the hideous behavior of introducing stutter when you actually are able to keep up with the intended rendering pace.
-
Yea that sounds helpful. Keep the stutter to a frame or so rather than letting it spread.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.