Ported my C game to WASM, here's every bug that I hit
ernesernesto.github.io
Ported my C game to WASM, here's every bug that I hit
1–10 of 116 posts
Re: Ported my C game to WASM, here's every bug that I hit
#2i want to hack 99 night in the forest
Re: Ported my C game to WASM, here's every bug that I hit
#3Meta: a space is missing in the title.
Since this is one of the bugs, I always recommemd writing
game->boardPieces = swAlloc(sizeof(ThingHandle*) * row * column);
game->boardPieces = swAlloc(sizeof *game->boardPieces * row * column);
Re: Ported my C game to WASM, here's every bug that I hit
#4The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
Re: Ported my C game to WASM, here's every bug that I hit
#5Why is a relatively new technology like WASM being limited to 32-bit pointers? Why repeat the same mistake again?
> Web is 32-bit. Your 64-bit structs will break. This was the root cause of most of my bugs. WASM is 32-bit address space, pointers are 4 bytes not 8.
Re: Ported my C game to WASM, here's every bug that I hit
#6Meta: a space is missing in the title. Since this is one of the bugs, I always recommemd writing game->boardPieces = swAlloc(sizeof(ThingHandle*) * row * column); Like this instead: game->boardPieces = swAlloc(sizeof *game->boardPieces * row * column); It's not 100% better, but it cuts out a few tokens which helps readability and moves the significant asterix further left where I think it's easier to spot.
> Meta: a space is missing in the title.
I like the word "everybug" :-D
Re: Ported my C game to WASM, here's every bug that I hit
#7Probably a firefox bug but the interface hit boxes are misaligned when fullscreen
Re: Ported my C game to WASM, here's every bug that I hit
#8The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
It's slower. Wasm32 can just reserve 8 GiB (32-bit pointer + 32-bit offset) of the virtual address space from the OS for each memory, so checking for out-of-bounds memory accesses imposes no performance penalty. Wasm64 can't do that, so each memory access is a bit slower.
Re: Ported my C game to WASM, here's every bug that I hit
#9I love how WASM is the thing that finally blurred the line between Web and Native programming, formely two realms isolated from each other for a long time. This both develops better awareness of how the code is executed by the hardware, which JavaScript devs often lack, and also brings skilled folks from the Native platforms who seem to be not so against WASM as they were against JavaScript (and all other parts of the Web, really). Maybe this will bear fruit in that people will make more Native user interfaces again.
Re: Ported my C game to WASM, here's every bug that I hit
#10The pointer size difference is the symptom, not the disease. Storing a raw pointer in a pak file was never valid even on native since the address changes every load, so the real fix is exactly what the author landed on, store an index into a side table instead of an embedded pointer. That offset based blob approach is what flatbuffers and console asset bakers use precisely so the same baked file loads identically across architectures and can be mmapped with zero fixups.