Hacker News Reader

Comment by midzer | Hacker News Reader

Celeste Classic in WASM https://midzer.de/wasm/celeste/

For some reason that runs at like double speed for me, very challenging.

Sounds like the game uses a fixed 60hz frame step but maybe you're on a 120hz display? Chrome and FF run requestAnimationFrame at 120hz in this case (while Safari sticks to 60hz)

Possibly, I'm indeed on a 120Hz display. I still got up to 1600m, it's a good challenge.

edit: 2000m now that I revisited. Crazy hard.

Made it to the summit at double speed.

  :strawberry:x14
  3:17:46
  deaths:1981

Don't link your world status updates to the frame rate please.

Even "AI"s know to show you how to do it in spite of requestAnimationFrame. I know, I asked.

But you have to ask them specifically to decouple game world updates from drawing, or they'll give you the dumb solution.

It's still a surprisingly tricky topic because simply measuring the frame duration (or using rAF's timestamp) gives significant timing jitter - which in turn introduces microstutter (and the other problem is that some browsers still limit timer precision to whole milliseconds due to the Specter/Meltdown fallout - but at least here the random jitter is useful because averaging over enough frames gives you the precise frame duration back, eg 16.667 or 8.333 ms instead of 15<=>17 or 7<=>9 ms

That’s no excuse if you ask me. Browsers aren’t consoles with fixed hardware. TBH not even consoles are fixed hardware any more …

Not an excuse, but the web platform should really offer better solutions to fix the microstutter problem when trying to implement a variable time step. Because currently there's no robust solution possible in "user space" (eg any type of noise removal filter will run into problems when the refresh rate suddenly changes, like moving the browser window to a display with different refresh rate).

Reply on news.ycombinator.com