Live data from Hacker News

Show HN: Porting Terraria and Celeste to WebAssembly

velzie.rip

51–55 of 55 posts

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#51
Amazing work. But I'm wondering, this is only for your own personal use right? Because the projects you are talking about here are still covered by copyright and thus even if you were the one who ported them to the web it's still not possibile to redistribute them for other people benefit.

If you are interested in taking a look, we run a cloud gaming service based on WASM at https://gaming.inlinestyle.it with cloud saves support. Many of things you discussed are related to what we had to do too, but we tried to do it only for opensource and freeware games so that everyone can benefit from them and play them on the cloud.

Appreciate any suggestion you have on how to improve the service!

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#52
post #46

Earlier quoted context omitted.

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)

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 1517 or 79 ms

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#53
post #29

I've recently started trying to do a bit of basic game development targeting the web through WASM+OpenGL+SDL, and I must say, I'm shocked with how easy it is. I spent more time fiddling with CMake files than I did trying to the code to run on the web. There are still some limitations and rough spots on the web platform, but I've honestly had a much harder time compiling things for Windows or MacOS than for WASM.

Dumb question: do you have access to any of the nice text rendering features of the browser when you use Wasm, or is it basically just drawing to a canvas

There's no difference between WASM and JS in this situation.

Once you are in canvas land, you'll have to do the text rendering yourself - that's not the fault of JS or WASM though, but of the broken web API stack (what's there is not properly layered, and the whole layer stack is inverted, e.g. canvas sits on top of the DOM instead the DOM sitting on top of canvas).

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#54
post #46

Earlier quoted context omitted.

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…

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

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#55
post #54

Earlier quoted context omitted.

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…

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).
Post reply on HN