Your tldr is badly off the mark. I'll spare you the epithets. If you did read the article in its entirety (which I doubt), you apparently did not understand what Alen was talking about.
-
-
-
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...
- 2 more replies
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.