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 …
I did read it all. As stated in the article, forcing fixed ticrate makes it go away but you can "get behind". My position is that you solve that not by varying tic interval but by skipping rendering the frame you missed.
-
-
My wording was unkind and a little hyperbolic though. Sorry about that.
-
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 -
-
-
... and from the demonstrated workaround you jumped to a conclusion that physics tickrate is the same as rendering/presentation rate? Shame. Again: this got nothing to do with physics. The problem is lack of info on when rendering you do gets to screen.
-
I don't see how you can render a frame at time t without having computed the physics state at time t. The example in the article had a rendering time that looked like it could not match a fixed physics ticrate.
-
Bah. All right, I've experienced a similar convo pattern before and I won't waste any more time here. The gap is too wide to bridge over a medium that has more latency than a face-to-face discussion.
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.