Live data from Hacker News

Show HN: Porting Terraria and Celeste to WebAssembly

velzie.rip

41–50 of 55 posts

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#41
post #32
post #23

Earlier quoted context omitted.

Even more interesting is this idea of running WebAssembly on the server, in containers, with orchestration services among them, and communicating across sandboxed environments. Somehow it reminds me of something, but memory is getting fuzzier nowadays. /s

You’re obviously talking about the 1972 VM/370 right?

Naturally.

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#42
post #23

> One of my favorite genres of weird project is "thing running in the browser that should absolutely not be running in the browser". Some of my favorites are the [...] the direct recompilation of Minecraft 1.12 Heh, you'd think Minecraft would be exactly the sort of thing that absolutely should be running in the browser, considering it was originally a Java applet. I understand the point, I just find it amusing.

Even more interesting is this idea of running WebAssembly on the server, in containers, with orchestration services among them, and communicating across sandboxed environments. Somehow it reminds me of something, but memory is getting fuzzier nowadays. /s

WebSphere!

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#44
Porting games to the web is a fun hobby! I've done Quake III [1] and Cave Story [2]. Just like in this story it's all about the details. Getting the game loading is just the start. Things like adding touch controls for mobile, handling multiplayer, managing save files, supporting modern screen resolutions and frame rates, they take more time than the initial port.

[1] Single player: https://thelongestyard.link/q3a-demo/ Multiplayer: https://thelongestyard.link/q3a-demo/?server=HN

[2] https://thelongestyard.link/cave-story/

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#46

Earlier quoted context omitted.

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)

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.

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#47
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 is an Emscripten library which cross-compiles things to WASM. The means you can generally just pull in a dependency for font rendering, such as SDL_ttf.

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#48

> One of my favorite genres of weird project is "thing running in the browser that should absolutely not be running in the browser". Some of my favorites are the [...] the direct recompilation of Minecraft 1.12 Heh, you'd think Minecraft would be exactly the sort of thing that absolutely should be running in the browser, considering it was originally a Java applet. I understand the point, I just find it amusing.

Early minecraft versions did run in the browser before it was made a standalone app, and they recreated it recently https://classic.minecraft.net

> recently

6 years ago? https://news.ycombinator.com/item?id=19861584

Re: Show HN: Porting Terraria and Celeste to WebAssembly

#49

Getting firebase "bandwidth quota exceeded" error when trying the demo. You shouldn't have to worry about this kind of stuff if it's just a static site. I'd host this on a cdn like cloudflare or github pages (free!).

My bad! Switched over to the github pages fallback. Cloudflare pages isn't suitable because the wasm files (100mb+) exceed the 25mb limit. (i could bypass this with service worker jank but that tends to be fragile). Github Pages also isn't suitable because it doesn't have a native way of sending the coi/coep headers that are required for SharedArrayBuffer to be available. Can also bypass that with service worker jank…

The service worker jank, while conceptually hacky, is actually remarkably un-janky and not really noticeable to users! It's very much fire-and-forget unless you also wanted to have another service worker (in which case it's time for suffering; service workers aren't even a little bit composable).

For anyone wondering: https://github.com/gzuidhof/coi-serviceworker or https://github.com/WebReflection/mini-coi

Post reply on HN