While I think this is nice, the tutorial is almost entirely unreadable on mobile.
WebAssembly from Scratch: From FizzBuzz to DooM
51–60 of 95 posts
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#52Nice read! I ported DOOM to TempleOS about a week ago. https://git.checksum.fail/alec/chocolate-doom
Doing the gods work, or the devil's work. I'm a little confused here.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#53Earlier quoted context omitted.
The problem is that each runtime has different GC requirements, so at best it will mean WASM GC semantics will be the underlying JS GC semantics, probably not what you want for a D or .NET GC, for example.
I would assume that there’s Microsoft folks involved to make sure it works out satisfactory given their investment in Blazor, but yes, it’s always a possibility that an API is bad. I don’t know what their level of interest is in embedding wasm inside C# is.
That was just an example, there are a plethora from GC algorithms to chose from, which of them needs to be fine tuned for the specific runtime it is to be applied, if performance is of any concern to the language implementers.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#54Earlier quoted context omitted.
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.
> I think if you're afraid of memory corruption inside the WASM heap, it's better to use Rust instead of C or C++.
Agreed, but as consumer from WASM modules that isn't your option to make.
> WASM's job is to prevent code inside the sandbox from escaping the sandbox, not to prevent memory corruption inside the sandbox.
That is not better than a typical OS process, just it happens to be randomly downloaded into my computer.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#55Earlier quoted context omitted.
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?
By having someone to pay me a proper salary. I don't do charity.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#56sorry if the answer is to read the whole series (i only read part 4), but is there a comparison of this hand-optimized route vs what emscripten outputs (in terms of binary size an browser perf)?
i assume a proper emscripten comparison would also need to strip networking & audio output.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#57Very 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…
Given that
> Doom has a global variable screens[0] which is a byte array of SCREENWIDTH*SCREENHEIGHT, i.e. 320x200 with the current screen contents.
It would seem to me that the right approach would be to hoist out Doom's main loop so you just have a renderFrame() function, then put something on the main browser thread to "blit" the image into the canvas itself.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#58Earlier 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.
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).
Any complex structure past int/floats requiere conversion. Heck, even floats and ints (for example: oCalm and anybody with more/less bits than JS).
So, given this is a fact, the best course of action is chosen the most safe alternative.
And for everyone else? Well an array of bits ant let the host/callers that are the only that know their own stuff deal with it.
INCLUDING Js.
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#59Interesting that Firefox by default did not render the fizzbuzz demo correctly by default. I had to click the canvas icon next to address bar and allow the canvas usage. And it did not show a prompt either. It just looked broken by default. Screenshot from Firefox vs Chrome https://i.imgur.com/Af8nTim.png
You probably have resist fingerprinting turned on
Most likely. I don't remember all the settings that I have turned on at some point. :)
Re: WebAssembly from Scratch: From FizzBuzz to DooM
#60Very 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…
Given that > Doom has a global variable screens[0] which is a byte array of SCREENWIDTH*SCREENHEIGHT, i.e. 320x200 with the current screen contents. It would seem to me that the right approach would be to hoist out Doom's main loop so you just have a renderFrame() function, then put something on the main browser thread to "blit" the image into the canvas itself.
As you wrote "the right approach would be", I'll add: That's exactly what the code does.