I should&
039;ve documented this better: the #fps parameter is indeed obsolete/ignored in 1.20. [Edit: updated the docs for
ig.main()].
In hindsight it was a bizarr idea to include this parameter anyway, because it gives the impression that you have any say in what the actual frame rate will be, when in reality you are, and always have been, at the mercy of the browser. You just
have to use the
tick instead of fixed values when calculating movements.
Now, the advantage of
requestAnimationFrame over
setInterval is that the browser tries to be smart instead of random.
The reason your game now runs with 75fps is that your display&
039;s refresh rate is 75hz - this is one of the main benefits of #requestAnimationFrame: The browser knows the refresh rate and adjusts the drawing interval accordingly.
In contrast, running a 60fps game on a 75hz display means that in the worst case one frame might be presented 16ms later than it was computed/drawn. Even worse: some frames are presented twice, some only once - this introduces an awkward jitter.
Consider this: at 60fps, one frame is
produced every ~16ms. Your 75hz display
presents a frame every ~13ms.
(Yay, ASCII table :D)
display ms: 0 13 26 39 52 65 78 91 104
game ms: 0 0 16 32 48 64 64 80 96
lag ms: 0 13 10 7 4 1 14 11 8
Your display will first refresh 13ms in, however there's no new frame to show, because the game only produces the next frame 16ms in. At the next refresh, 26ms in, the frame that was produced at 16ms is finally shown - a lag of 10ms. Also notice that some frames are displayed twice, while others are only displayed once.
Converting movies from the big screen (24fps) to TV (60fps) meets the same challenge. They're smarter than just presenting the same frame twice, but it still introduces visual artifacts: "
there are four frames of film for every five frames of 60 Hz video". That's why the 24hz mode of modern TVs is such a big deal.
tldr: It&
039;s a good thing that the browser decides the frame rate and I won't bring back the #fps parameter.
