pancelor
commented
1 year ago Hey there! I'm finally getting back to you on this. You raised some good points that make smoothing out the framerate seem not especially important -- maybe this small mostly-unnoticeable tweak would suddenly break things, e.g., people with a 160fps monitor would now have their games run at 2.5x speed. I wouldn't want that!
But today I realized that there's a nasty timing discrepancy between browsers (#949) -- chrome runs games 1.3x slower than firefox, for my test case! I suspected that switching to requestAnimationFrame would fix it, and it did, so I've remade the PR as #948.
The fact that it's not tied to a set framerate means I don't want it. Puzzlescript games don't need to update faster than that (and probably could be optimized to update considerably less often in most cases ) and I don't want to be a bad citizen in cases where someone with a 160fps monitor opens up a puzzlescript game and weird things happen.
I've fixed this -- 160fps monitors might run games 2~3x faster than they should on #924, but they will now run at the correct speed on #949.
is there a better callback for canvas updates?
As far as I know, this is "the correct way". In all the resources I've seen the only options I've ever heard of are requestAnimationFrame and setTimeout/setInterval (and every one that mentions both says "this is why setTimeout/setInterval are bad and you should use requestAnimationFrame instead" as far as I remember; here's an example or two. and here's a game loop library that looks well-thought-out and relies on requestAnimationFrame)
I agree that the docs make it look like a DOM manipulation thing, but maybe DOM manipulation is just a much easier example to write than setting up a canvas element, which explains why they wrote it that way? Just a hunch.
cf https://github.com/increpare/PuzzleScript/pull/924
Ok the frame-skipping is interesting! I will definitely look more into this.
The fact that it's not tied to a set framerate means I don't want it. Puzzlescript games don't need to update faster than that (and probably could be optimized to update considerably less often in most cases ) and I don't want to be a bad citizen in cases where someone with a 160fps monitor opens up a puzzlescript game and weird things happen.
The other interesting question is: is there a better callback for canvas updates? It's not totally clear that "Window.requestAnimationFrame" is the place - that seems more concerned with dom manipulation, but maybe there's somewhere else...hmm...interesting!