Live data from Hacker News

WebAssembly from Scratch: From FizzBuzz to DooM

github.com

41–50 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#41

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performan…

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…

[deleted]

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#42
I love seeing this kind of tutorial, that isn't just a step-by-step guide, but also an exploration of the thought process and trial-and-error that goes on in crafting each step, so thanks for sharing.

Looks like a lot of the work on the Doom port (https://github.com/diekmann/wasm-fizzbuzz/tree/main/doom) is about getting common functions from the C standard library to work in WASM. Surely this seems like a good opportunity for a new Free Software initiative - something optimized, properly licensed/credited and easy for everybody to use?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#43

Earlier quoted context omitted.

I feel the same way. I find it very odd that GC is something that WASM ever intends to think about. If shipping your entire runtime sucks, find a smaller runtime?

Think of it more of "integration with a host environment's runtime" than a "adding a runtime to wasm directly." (At least, that's what it used to be; I haven't been involved in WebAssembly for a long time.)

Yeah, could be interesting. I guess it works for the JVM? I feel like people will still want to use their own runtimes but idk

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#46
post #32

Earlier quoted context omitted.

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Ja…

>What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.

This would still require conversion from and to Javascript strings, and doesn't help with any language compiled to WASM that isn't Rust. And it probably wouldn't even help Rust because such a native WASM string type would presumably live outside the WASM heap (because if the string data would be on the WASM heap, there's no need for a native string type).

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#47
post #34
post #32

Earlier quoted context omitted.

>What type of strings though? The good one! UTf-8, NOT null terminated, pascal like. ie: what rust have: https://doc.rust-lang.org/std/string/struct.String.html REPEAT the mistakes of C (and considering the security angle! in a browser!) must be a big no.

Unfortunely that is not what WASM designers decided when they went without memory tagging for linear memory segments. So you get all the fun to corrupt linear memory C style.

I think if you're afraid of memory corruption inside the WASM heap, it's better to use Rust instead of C or C++. WASM's job is to prevent code inside the sandbox from escaping the sandbox, not to prevent memory corruption inside the sandbox.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#48
post #28

Just a point for the first chapters: you are not required to run your own local server (even if things push in that direction) You can include the wasm as an ArrayBuffer or as a base64 encoded string and hardcode it in the javascript. Now it will run even in a static html.

It's incredible how far the web has come. I remember the first time I saw a browser GameBoy emulator and I was amazed. Maybe I should port my GB emulator to WASM...

> It's incredible how far the web has come.

I agree and disagree. It seems like no one is questioning why we need to use legacy web browsers in between all the code we're executing locally.

It's like a new iteration of old tech like lisp machines, which started out as specific purpose only to grow into complete environments (afaik).

In this regard, we haven't come far, it's just the syntax that has changed.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#49
post #33

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performan…

Pity that WebAssembly Studio development seems to have stalled. https://webassembly.studio/ It is the easiest way to get into WASM. Threading requires sending custom headers by the way.

Any thoughts on how you could revive it?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#50

My first question I thought of before reading this was how to actually display characters out of it. Quite a mess, IMHO. (Not that I'm blaming the author).

This is common for lower-level API though. Displaying a single cube in modern OpenGL or Vulkan is also surprisingly a mess.
Post reply on HN