7 ms·

Ported my C game to WASM, here's every bug that I hit

119 points by birdculture 5mo ago

pioh 4mo ago
i want to hack 99 night in the forest
unwind 4mo ago
Meta: 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.
- ErroneousBosh 4mo ago
  > Meta: a space is missing in the title. I like the word "everybug" :-D
- quietbritishjim 4mo ago
  Honestly, I think I'm more likely to get your form wrong than the original one. This doesn't obviously look wrong to me: game->boardPieces = swAlloc(sizeof game->boardPieces * row * column); Maybe I find this harder to parse because I'm not used to sizeof without brackets (though I know it's valid). But I think the bigger deal is that your version has a bug if the star is missing whereas there's has a bug if the star is present; it's easier to spot something extra than it is to spot something missing.
- jstimpfle 4mo ago
  It's totally true, using sizeof like a function is one of my pet peeves. Even the kernel people do it but it's WRONG and you are right. But ACSHUALLY, how you write allocation is like this #define sane_alloc(type, count) ((type *) malloc(sizeof (type) * (count))) game->boardPieces = sane_alloc(BoardPiece, row * column); The kernel people seem to finally have figured out this one in 2026.
  - DonHopkins 4mo ago
    Nothing is sane in a language that lets you say 4["Foo!"] Array indexing in C is just pointer arithmetic wearing Groucho Marx Glasses. C combines the flexibility and power of assembly language with the user-friendliness of assembly language.
    - jstimpfle 4mo ago
      > Nothing is sane in a language that lets you say 4["Foo!"] I just had a look at your HN profile page and was struck by the irony of seeing your Forth vs Lisp vs Postscript code examples there. Now consider that I've never written code like 4["Foo!"], even though I know it's possible, but in other languages you constantly have to do mental gymnastics to get any real work done, and those are allegedly so much saner !???
      - DonHopkins 4mo ago
        When they were handing out brains, I though they said suᴉɐɹq, and I said "180 rotate".
  - unwind 4mo ago
    Nah I'm still against repeating the type name all over the place, and the cast adds nothing good imnsho.
    - jstimpfle 4mo ago
      The cast is at least 50% of why this is useful! You'll now get compile errors in case you did anything wrong.
- Joker_vD 4mo ago
  Frankly, "sizeof(T*)" should generate a warning if T is anything other than void, or a function type. Yes, I know that C technically allows rather heterogenous representations for pointers to different types, but in practice there is difference only between object pointers and function pointers.
xydone 4mo ago
The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
- sestep 4mo ago
  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.
  - xydone 4mo ago
    Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
  - senfiaj 4mo ago
    Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
    - flohofwoe 4mo ago
      > The bridge will add more latency when there is a transition between JS and wasm. This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
      - deleted 4mo ago
        [deleted]
- 4mo ago
thewavelength 4mo ago
Why 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.
- whizzter 4mo ago
  1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization). 2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific rules in JS to get reliable 32bit arithmetic (but impossible for 64bit). Wasm64 is implemented and works in Chrome and Firefox.. Apple is lagging again with Safari.
  - thewavelength 4mo ago
    Thanks! 1: True, although it also limits the addressable memory and the typical 4GB limit seems less these days. I’m thinking of large apps like Figma running in the browser. 2: Will existing 32-bit WASM binaries break on WASM64 engines or does the binary have a flag for compatibility?
    - koolala 4mo ago
      what would make it break? i think the program just calls a 64 bit wasm memory function if it uses the capability
    - whizzter 4mo ago
      1: Something like Figma could probably offload some of the memory pressure to GPU textures. (But they'd probably run into safety browser limits before that). 2: Most runtimes are 64bit already, A runtime detecting a wasm32 binary will just continue to generate code with the current JIT compiler whilst WASM64 will require another JIT (and perhaps memory system since WASM32 runtimes are often based on "hacks" where 4gb of address space is reserved but not given real memory so that the JIT compiler gets an easier job without security implications).
nhinck3 4mo ago
Probably a firefox bug but the interface hit boxes are misaligned when fullscreen
arcadialeak 4mo ago
I 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.
- gspr 4mo ago
  I wanted to love it. As someone who hasn't done any web stuff since I was a child, I thought it'd amazing for it to be "just another platform". I'm a bit disappointed though: * There's still no way to do DOM manipulation. So then it's tempting to just grab a canvas and draw everything yourself, which of course wreaks on things like accessibility. I'm no fan of the web, but at least it comes with a somewhat agreed-upon way to display graphical stuff – it's a bit of a shame if we're all gonna just treat it like a surface for pixels. * WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way? I understand that sandboxing is important, so this can all be on a per-request-basis, but still. This "just another platform" is still too far from just that. * The amount of JS glue needed to actually load WASM stuff in the browser is annoying. The idea of needing a bunch of magic "bundlers" is sad.
  - samiv 4mo ago
    You can call JS in which you can manipulate the DOM. Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web. This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.
    - gspr 4mo ago
      > You can call JS in which you can manipulate the DOM. Well sure. But for me, the promise of WASM was to make the browser "just another platform". Now it's "this special platform where you have to access some of the most important functionality through FFI interop with a very high-level, very opinionated language". > Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web. OK, but like, I wanted the browser to be "just another platform". I don't want to use JS, and I consider HTML orthogonal to my logic. I realize that's not where we're at, but that's what I dreamt of. Hence my disappointment. Which is OK, I don't matter :) > This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing. It feels the opposite to me.
haeseong 4mo ago
The 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.
rvz 4mo ago
If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1] [0] https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.pdf https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.p... [1] https://www.usenix.org/system/files/sec20-lehmann.pdf https://www.usenix.org/system/files/sec20-lehmann.pdf
- pjmlp 4mo ago
  No worries, it is sandboxed. /s
  - yjftsjthsd-h 4mo ago
    Why /s? That does massively reduce the exposure
    - pjmlp 4mo ago
      As much as an OS process, on a modern OS that is. The bounds checking story is only on the external limits of linear memory segments. If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker. Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode. It is only yet another one since various others that came and went since UNCOL became an idea.
      - koolala 4mo ago
        How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
        pjmlp 4mo ago
        Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.
diath 4mo ago
With regards to 1), do not write/read structs directly to/from files. Instead write a proper serializer/deserializer. Without it, you may encounter another breakage soon when a different compiler/compiler options insert different struct padding bytes, which will then once again make your data non-portable, and a maliciously crafted save file with no length/size field validation on the deserializer level can lead to a variety of memory bugs.
- jstimpfle 4mo ago
  struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
  - leni536 4mo ago
    Specified by whom? Not the C standard for sure. It is indeed soecified by individual ABIs, and ABIs don't tend to do anything too weird, but that's another question.
    - jstimpfle 4mo ago
      looks like I was wrong, but here is the de-facto standard I was relying on over the years ;-). Not that I've memcpied many structs to file directly btw. http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/
      - jcranmer 4mo ago
        The general struct layout algorithm is that you lay out the first member at the address of the struct (this is guaranteed by C), and then subsequent fields in order (also guaranteed by C). What isn't guaranteed is how fields get their alignment, in particular shenanigans you can do with allocating fields in the padding of their prior field, and bitfields in general are horribly underspecified. In practice, C doesn't do any padding shenanigans, but C++ does (but only for non-POD structs, and then you discover there's several slightly different definitions that mean basically "POD", so have fun predicting which one is the one that actually matters for your use case).
hiccuphippo 4mo ago
Fun game! The demo works great on mobile except for some small font sizes and you can't hover over items to see the tooltip before selecting them.
senfiaj 4mo ago
[dead]
Someone 4mo ago
FTA: I was serializing asset structs directly to disk (pak file) that had raw pointers in them I’m surprised that that works in WASM. Wouldn’t a tiny change in your memory usage (say if you toggle your “log startup progress” flag) load data at a different address?
- mwkaufma 4mo ago
  Usually you do "pointer-fixup" where you convert them to relative-offsets on write and then back to absolute-offsets on read.
DonHopkins 4mo ago
I've been porting Micropolis (SimCity Classic) to WASM / WebGPU / Svelte 5. Emscripten + Embind compile the C++ engine and glue it to TypeScript/Svelte/Runes/Reactivity; TypeScript owns UI, rendering, and callback handlers. I agree with the article's main lessons: wasm32 pointer size, don't serialize structs with pointers, debug native 32-bit when you can, WebGL/WebGPU is stricter than desktop GL, Emscripten export flags still bite. I hit some of the same categories; the parts that were actually tricky for Micropolis are below. Svelte 5 runes ($state, $derived, etc.) work in plain .ts modules, not just .svelte templates. That matters because the WASM bridge is a reactive module the HUD, command bus, and Vitest all import -- not a component-only trick. The file has to be MicropolisReactive.svelte.ts so runes compile under the same Vite/SvelteKit pipeline as the app; plain .ts breaks in Node with "$state is not defined". Embind API surface -- what to expose and what to leave out: https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/emscripten.cpp https://github.com/SimHacker/MicropolisCore/blob/main/packag... // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. The comments in that file go on to describe the strategy for wrapping: Core Simulation Logic, Memory and Performance Considerations, Direct Memory Access, User Interface and Rendering, Callbacks and Interactivity, and Optimizations. The engine callback virtual interface bridged C++ to JS via JSCallback: https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/js_callback.h https://github.com/SimHacker/MicropolisCore/blob/main/packag... In the old NeWS/Hyperlook, TCL/Tk/X11, SWIG/Python/PyGTK, and SWIG/Python/TurboGears/AMF/Flash versions, this callback interface used to be a stringly typed general purpose event callback interface, which I tightened up into a strict C++ interface and corresponding typescript interface, so embind could help me integrate it safely and cleanly with TypeScript and Svelte Runes. TypeScript handlers that update rune-backed state (sendMessage, didTool, budget hooks, etc.): https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisReactive.svelte.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... Simulator attach/detach, singleton engine load, wiring JSCallback into Micropolis: https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisSimulator.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... The pattern: C++ fires callbacks with enough context for the UI; TS updates $state; components read micropolisReactive (peek / poke / memory / getSnapshot) instead of calling Embind or touching HEAP* directly. That is where the rubber hits the road for interactivity. Heap access is its own footgun. Emscripten may expose Module.wasmMemory, HEAPU16, or neither until init; some getters throw if you read too early. Centralized helper: https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/wasm/heap.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... Bridge design, Vitest against real WASM, teardown order with Embind lifetimes: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/wasm-bridge-and-testing-trajectory.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Map rendering: WebGPU tile renderer with canvas fallback (legacy WebGL frozen, now reimplementing in WebGPU). The renderer reads 16 bit flags + tile indices from direct simulator memory views into WASM linear memory (mapData / mopData), not per-frame Embind copies. https://github.com/SimHacker/MicropolisCore/blob/main/packages/tile-renderer/src/WebGPUTileRenderer.ts https://github.com/SimHacker/MicropolisCore/blob/main/packag... https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... City saves are a defined binary format (.cty), not fwrite of engine structs. Live map data is views into WASM linear memory (mapData / mopData), not embedded native pointers -- same idea as the article's side-table fix, but that is how this codebase is already structured. Why I find this stack interesting: original SimCity engine lineage, narrow Embind surface on purpose, reactive TS facade so automation and UI share one sim without reviving the old Python/SWIG/pyGTK path. Sprites (trains, choppers, generic orange monsters wrecking chaos and havoc -- definitely not Godzilla [TM], but possibly Trump adjacent) simulate in C++; compositing them in the WebGPU path is still work in progress. The WebGPU renderer is being built as a general stack with pluggable layers, including Sims content rendering (characters, animations, terrain, objects, walls, floors, ui effects, etc). Character animation demo: https://vitamoo.space https://vitamoo.space VitaMoo code: https://github.com/SimHacker/MicropolisCore/tree/main/packages/vitamoo https://github.com/SimHacker/MicropolisCore/tree/main/packag... Unified WebGPU Renderer: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Render Core Package: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/render-core-package.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Renderer Plugin Roadmap: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/renderer-plugin-roadmap.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Live Micropolis tile renderer and simulator demo (no other ui yet, work in progress): https://micropolisweb.com https://micropolisweb.com Demo of the simulator, cellular automata, and tile engine to Jerry Martin's music: https://www.youtube.com/watch?v=319i7slXcbI https://www.youtube.com/watch?v=319i7slXcbI Repo: https://github.com/SimHacker/MicropolisCore https://github.com/SimHacker/MicropolisCore
hexer303 4mo ago
I just finished a similar project for fun and education. It was a 20-year-old codebase from my old game in win32 and DirectX 9. I first ported it to native and also switched to bgfx for rendering. This was the bulk of the work - converting all of the old DirectX fixed function pipeline code to shaders. Luckily all modern shaders can simulate all of the old fixed-function DX pipeline features with little effort. Including the coordinate system. Loading DDS textures didn't present a major challenge either. Had similar native asset loading as yours - no deserializer. It loaded an entire asset file into a preallocated memory block, used packed structures and converted file offsets to pointers after loading. I had to convert it to 64bit for native first. The most surprising thing: I had no idea WASM is 32bit until I read your article! Once I ported to 64bit, I then ported to WASM and I didn't even encounter any arch related bugs. In hindsight I guess it's because most of the original code was 32bit and the asset file format is still 32bit format. When I ported to 64bit I used a deserializer, so I guess that's why it all worked out in the end. For native audio I ended up using SoLoud library, but for emscripten I #ifdef'd it out to use inline JS instead. I figured there is no point in having all that extra audio library code compiling to WASM when modern browsers natively support playing audio, oggvorbis, etc. It worked out ok, but there's still a minor bug where the music doesn't loop perfectly. You can hear a split second gap between end/start. I haven't looked deeply into it yet. Originally when we wrote the game we had banned ourselves from using C++ Exception handling and RTTI. The decision likely paid off as it makes the generated binary smaller and faster. Although I haven't had time to measure. Supposedly C++ exceptions introduce a much heavier overhead in Emscripten. You can see the port in action at https://scorchedplanets.com https://scorchedplanets.com
- flohofwoe 4mo ago
  > I had no idea WASM is 32bit until I read your article! WASM(32) is a hybrid 32/64 bit architecture. The address range (and thus pointer size) is 32 bits, but it has native 64-bit integers. E.g. it's similar to the Linux x32 ABI. There is also a 'true' 64-bit wasm, but that's still too recent to be used in real-world code: https://caniuse.com/wf-wasm-memory64 https://caniuse.com/wf-wasm-memory64 (but wasm64 doesn't really make sense unless you really need an address space greater than 32 bits, because the downside is slower performance)
fyrn_ 4mo ago
You can get real breakpoints, memory watching, etc in browser with the chrome debugging extension
- flohofwoe 4mo ago
  I would recommend the VSCode WASM DWARF debugging extension instead of the Chrome extension nowadays: https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod... This allows to setup an IDE-like 'press F5 to build and start into a debug session' in VSCode, with the debuggee running in Chrome. E.g. see: https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
  - fyrn_ 4mo ago
    More of a helix user these days. I will look into it though. Thanks for sokol btw, we use it at work for some things. Mainly gfx and the dds encoder
deadbabe 4mo ago
Is it better to render directly in WASM or could you do game logic in WASM and then render in JavaScript with a JS graphics engine?
Panzerschrek 4mo ago
I did the same with one of small games I have developed. It wasn't that hard. I only needed to tweak the build script and to fix some minor issues, like changing how main function works and swapping color components in the result picture. I did use SDL2 for it, but without OpenGL, so, I had no problems with shaders or something similar.
Anais_Elena14 4mo ago
fain
Anais_Elena14 4mo ago
fain big

119 points by birdculture 5mo ago

pioh 4mo ago

i want to hack 99 night in the forest

Meta: 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.

ErroneousBosh 4mo ago
> Meta: a space is missing in the title. I like the word "everybug" :-D
quietbritishjim 4mo ago
Honestly, I think I'm more likely to get your form wrong than the original one. This doesn't obviously look wrong to me: game->boardPieces = swAlloc(sizeof game->boardPieces * row * column); Maybe I find this harder to parse because I'm not used to sizeof without brackets (though I know it's valid). But I think the bigger deal is that your version has a bug if the star is missing whereas there's has a bug if the star is present; it's easier to spot something extra than it is to spot something missing.
jstimpfle 4mo ago
It's totally true, using sizeof like a function is one of my pet peeves. Even the kernel people do it but it's WRONG and you are right. But ACSHUALLY, how you write allocation is like this #define sane_alloc(type, count) ((type *) malloc(sizeof (type) * (count))) game->boardPieces = sane_alloc(BoardPiece, row * column); The kernel people seem to finally have figured out this one in 2026.
- DonHopkins 4mo ago
  Nothing is sane in a language that lets you say 4["Foo!"] Array indexing in C is just pointer arithmetic wearing Groucho Marx Glasses. C combines the flexibility and power of assembly language with the user-friendliness of assembly language.
  - jstimpfle 4mo ago
    > Nothing is sane in a language that lets you say 4["Foo!"] I just had a look at your HN profile page and was struck by the irony of seeing your Forth vs Lisp vs Postscript code examples there. Now consider that I've never written code like 4["Foo!"], even though I know it's possible, but in other languages you constantly have to do mental gymnastics to get any real work done, and those are allegedly so much saner !???
    - DonHopkins 4mo ago
      When they were handing out brains, I though they said suᴉɐɹq, and I said "180 rotate".
- unwind 4mo ago
  Nah I'm still against repeating the type name all over the place, and the cast adds nothing good imnsho.
  - jstimpfle 4mo ago
    The cast is at least 50% of why this is useful! You'll now get compile errors in case you did anything wrong.
Joker_vD 4mo ago
Frankly, "sizeof(T*)" should generate a warning if T is anything other than void, or a function type. Yes, I know that C technically allows rather heterogenous representations for pointers to different types, but in practice there is difference only between object pointers and function pointers.

xydone 4mo ago

The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?

sestep 4mo ago
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.
- xydone 4mo ago
  Oh that's interesting, never noticed it in my experience but I have never written anything in wasm where it would matter. Makes perfect sense now that I think about it though. Thanks!
- senfiaj 4mo ago
  Sometimes I wonder whether it's possible to run the wasm code in a separate sandboxed process to eliminate a lot of checks. I mean optionally, because normally JS calls wasm code synchronously in the same address space. The bridge will add more latency when there is a transition between JS and wasm. It's obviously complicated because some data structures can also be shared, such as SharedArrayBuffer.
  - flohofwoe 4mo ago
    > The bridge will add more latency when there is a transition between JS and wasm. This would be similar to how NaCl/PNaCl communicated with the JS side (via message passing), and that really sucked and would also be prohibitively slow for talking to 'high frequency APIs' like WebGL2 or WebGPU (or the DOM heh).
    - deleted 4mo ago
      [deleted]
4mo ago

thewavelength 4mo ago

Why 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.

whizzter 4mo ago
1: Letting your code break on pointer size changes is a quite bad sign imho (it's a sign that many other things are probably done with aliasing,etc and has a high risk of breaking due to undefined behaviour once gcc/clang gets around to utilizing it for an optimization). 2: iirc WASM was initially designed to be shimmable via Asm.JS to force laggards(Apple, Google) to implement it, Asm.JS in turn relied on specific rules in JS to get reliable 32bit arithmetic (but impossible for 64bit). Wasm64 is implemented and works in Chrome and Firefox.. Apple is lagging again with Safari.
- thewavelength 4mo ago
  Thanks! 1: True, although it also limits the addressable memory and the typical 4GB limit seems less these days. I’m thinking of large apps like Figma running in the browser. 2: Will existing 32-bit WASM binaries break on WASM64 engines or does the binary have a flag for compatibility?
  - koolala 4mo ago
    what would make it break? i think the program just calls a 64 bit wasm memory function if it uses the capability
  - whizzter 4mo ago
    1: Something like Figma could probably offload some of the memory pressure to GPU textures. (But they'd probably run into safety browser limits before that). 2: Most runtimes are 64bit already, A runtime detecting a wasm32 binary will just continue to generate code with the current JIT compiler whilst WASM64 will require another JIT (and perhaps memory system since WASM32 runtimes are often based on "hacks" where 4gb of address space is reserved but not given real memory so that the JIT compiler gets an easier job without security implications).

nhinck3 4mo ago

Probably a firefox bug but the interface hit boxes are misaligned when fullscreen

arcadialeak 4mo ago

I 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.

gspr 4mo ago
I wanted to love it. As someone who hasn't done any web stuff since I was a child, I thought it'd amazing for it to be "just another platform". I'm a bit disappointed though: * There's still no way to do DOM manipulation. So then it's tempting to just grab a canvas and draw everything yourself, which of course wreaks on things like accessibility. I'm no fan of the web, but at least it comes with a somewhat agreed-upon way to display graphical stuff – it's a bit of a shame if we're all gonna just treat it like a surface for pixels. * WASI still leaves something to be desired. Why can't I have raw sockets and file access and stuff, in a POSIX-like way? I understand that sandboxing is important, so this can all be on a per-request-basis, but still. This "just another platform" is still too far from just that. * The amount of JS glue needed to actually load WASM stuff in the browser is annoying. The idea of needing a bunch of magic "bundlers" is sad.
- samiv 4mo ago
  You can call JS in which you can manipulate the DOM. Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web. This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing.
  - gspr 4mo ago
    > You can call JS in which you can manipulate the DOM. Well sure. But for me, the promise of WASM was to make the browser "just another platform". Now it's "this special platform where you have to access some of the most important functionality through FFI interop with a very high-level, very opinionated language". > Of course architecturally (also regarding your file access) it's better to use the wasm for logic as much as possible where the web (HTML/JS) provides the UI and IO, data flows into wasm for work and results flow back to the web. OK, but like, I wanted the browser to be "just another platform". I don't want to use JS, and I consider HTML orthogonal to my logic. I realize that's not where we're at, but that's what I dreamt of. Hence my disappointment. Which is OK, I don't matter :) > This also has the benefit that you can keep your original C/C++ source code much more platform agnostic which helps reusability and testing. It feels the opposite to me.

haeseong 4mo ago

The 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.

rvz 4mo ago

If you are porting anything from C into WebAssembly, keep in mind that you still inherit C based vulnerabilities. [0] [1] [0] https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.pdf https://soft.vub.ac.be/Publications/2022/vub-tr-soft-22-02.p... [1] https://www.usenix.org/system/files/sec20-lehmann.pdf https://www.usenix.org/system/files/sec20-lehmann.pdf

pjmlp 4mo ago
No worries, it is sandboxed. /s
- yjftsjthsd-h 4mo ago
  Why /s? That does massively reduce the exposure
  - pjmlp 4mo ago
    As much as an OS process, on a modern OS that is. The bounds checking story is only on the external limits of linear memory segments. If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker. Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode. It is only yet another one since various others that came and went since UNCOL became an idea.
    - koolala 4mo ago
      How could any general execution environment guarantee memory like that? That doesn't seem like a realistic expectation. You can write safe Rust code if you want memory guarantees in WASM but would you really want it to block the ability to run unsafe Rust code too?
      - pjmlp 4mo ago
        Easy, see other bytecodes with bounds checking opcodes, and where use of unsafe bytecodes taint the executable on the verifier, which then requires explicit execution permission.

diath 4mo ago

With regards to 1), do not write/read structs directly to/from files. Instead write a proper serializer/deserializer. Without it, you may encounter another breakage soon when a different compiler/compiler options insert different struct padding bytes, which will then once again make your data non-portable, and a maliciously crafted save file with no length/size field validation on the deserializer level can lead to a variety of memory bugs.

jstimpfle 4mo ago
struct layout is well specified, it should be possible to avoid any padding issues by just aligning and by padding (with dummy members) correctly. The problem in practice is mostly integer representation (big-endian vs little-endian).
- leni536 4mo ago
  Specified by whom? Not the C standard for sure. It is indeed soecified by individual ABIs, and ABIs don't tend to do anything too weird, but that's another question.
  - jstimpfle 4mo ago
    looks like I was wrong, but here is the de-facto standard I was relying on over the years ;-). Not that I've memcpied many structs to file directly btw. http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/
    - jcranmer 4mo ago
      The general struct layout algorithm is that you lay out the first member at the address of the struct (this is guaranteed by C), and then subsequent fields in order (also guaranteed by C). What isn't guaranteed is how fields get their alignment, in particular shenanigans you can do with allocating fields in the padding of their prior field, and bitfields in general are horribly underspecified. In practice, C doesn't do any padding shenanigans, but C++ does (but only for non-POD structs, and then you discover there's several slightly different definitions that mean basically "POD", so have fun predicting which one is the one that actually matters for your use case).

hiccuphippo 4mo ago

Fun game! The demo works great on mobile except for some small font sizes and you can't hover over items to see the tooltip before selecting them.

senfiaj 4mo ago

[dead]

Someone 4mo ago

FTA: I was serializing asset structs directly to disk (pak file) that had raw pointers in them I’m surprised that that works in WASM. Wouldn’t a tiny change in your memory usage (say if you toggle your “log startup progress” flag) load data at a different address?

mwkaufma 4mo ago
Usually you do "pointer-fixup" where you convert them to relative-offsets on write and then back to absolute-offsets on read.

DonHopkins 4mo ago

I've been porting Micropolis (SimCity Classic) to WASM / WebGPU / Svelte 5. Emscripten + Embind compile the C++ engine and glue it to TypeScript/Svelte/Runes/Reactivity; TypeScript owns UI, rendering, and callback handlers. I agree with the article's main lessons: wasm32 pointer size, don't serialize structs with pointers, debug native 32-bit when you can, WebGL/WebGPU is stricter than desktop GL, Emscripten export flags still bite. I hit some of the same categories; the parts that were actually tricky for Micropolis are below. Svelte 5 runes ($state, $derived, etc.) work in plain .ts modules, not just .svelte templates. That matters because the WASM bridge is a reactive module the HUD, command bus, and Vitest all import -- not a component-only trick. The file has to be MicropolisReactive.svelte.ts so runes compile under the same Vite/SvelteKit pipeline as the app; plain .ts breaks in Node with "$state is not defined". Embind API surface -- what to expose and what to leave out: https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/emscripten.cpp https://github.com/SimHacker/MicropolisCore/blob/main/packag... // This file uses emscripten's embind to bind C++ classes, // C structures, functions, enums, and contents into JavaScript, // so you can even subclass C++ classes in JavaScript, // for implementing plugins and user interfaces. // // Wrapping the entire Micropolis class from the Micropolis (open-source // version of SimCity) code into Emscripten for JavaScript access is a // large and complex task, mainly due to the size and complexity of the // class. The class encompasses almost every aspect of the simulation, // including map generation, simulation logic, user interface // interactions, and more. The comments in that file go on to describe the strategy for wrapping: Core Simulation Logic, Memory and Performance Considerations, Direct Memory Access, User Interface and Rendering, Callbacks and Interactivity, and Optimizations. The engine callback virtual interface bridged C++ to JS via JSCallback: https://github.com/SimHacker/MicropolisCore/blob/main/packages/micropolis-engine/src/js_callback.h https://github.com/SimHacker/MicropolisCore/blob/main/packag... In the old NeWS/Hyperlook, TCL/Tk/X11, SWIG/Python/PyGTK, and SWIG/Python/TurboGears/AMF/Flash versions, this callback interface used to be a stringly typed general purpose event callback interface, which I tightened up into a strict C++ interface and corresponding typescript interface, so embind could help me integrate it safely and cleanly with TypeScript and Svelte Runes. TypeScript handlers that update rune-backed state (sendMessage, didTool, budget hooks, etc.): https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisReactive.svelte.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... Simulator attach/detach, singleton engine load, wiring JSCallback into Micropolis: https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/MicropolisSimulator.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... The pattern: C++ fires callbacks with enough context for the UI; TS updates $state; components read micropolisReactive (peek / poke / memory / getSnapshot) instead of calling Embind or touching HEAP* directly. That is where the rubber hits the road for interactivity. Heap access is its own footgun. Emscripten may expose Module.wasmMemory, HEAPU16, or neither until init; some getters throw if you read too early. Centralized helper: https://github.com/SimHacker/MicropolisCore/blob/main/apps/micropolis/src/lib/wasm/heap.ts https://github.com/SimHacker/MicropolisCore/blob/main/apps/m... Bridge design, Vitest against real WASM, teardown order with Embind lifetimes: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/wasm-bridge-and-testing-trajectory.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Map rendering: WebGPU tile renderer with canvas fallback (legacy WebGL frozen, now reimplementing in WebGPU). The renderer reads 16 bit flags + tile indices from direct simulator memory views into WASM linear memory (mapData / mopData), not per-frame Embind copies. https://github.com/SimHacker/MicropolisCore/blob/main/packages/tile-renderer/src/WebGPUTileRenderer.ts https://github.com/SimHacker/MicropolisCore/blob/main/packag... https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... City saves are a defined binary format (.cty), not fwrite of engine structs. Live map data is views into WASM linear memory (mapData / mopData), not embedded native pointers -- same idea as the article's side-table fix, but that is how this codebase is already structured. Why I find this stack interesting: original SimCity engine lineage, narrow Embind surface on purpose, reactive TS facade so automation and UI share one sim without reviving the old Python/SWIG/pyGTK path. Sprites (trains, choppers, generic orange monsters wrecking chaos and havoc -- definitely not Godzilla [TM], but possibly Trump adjacent) simulate in C++; compositing them in the WebGPU path is still work in progress. The WebGPU renderer is being built as a general stack with pluggable layers, including Sims content rendering (characters, animations, terrain, objects, walls, floors, ui effects, etc). Character animation demo: https://vitamoo.space https://vitamoo.space VitaMoo code: https://github.com/SimHacker/MicropolisCore/tree/main/packages/vitamoo https://github.com/SimHacker/MicropolisCore/tree/main/packag... Unified WebGPU Renderer: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/unified-webgpu-renderer.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Render Core Package: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/render-core-package.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Renderer Plugin Roadmap: https://github.com/SimHacker/MicropolisCore/blob/main/documentation/designs/renderer-plugin-roadmap.md https://github.com/SimHacker/MicropolisCore/blob/main/docume... Live Micropolis tile renderer and simulator demo (no other ui yet, work in progress): https://micropolisweb.com https://micropolisweb.com Demo of the simulator, cellular automata, and tile engine to Jerry Martin's music: https://www.youtube.com/watch?v=319i7slXcbI https://www.youtube.com/watch?v=319i7slXcbI Repo: https://github.com/SimHacker/MicropolisCore https://github.com/SimHacker/MicropolisCore

hexer303 4mo ago

I just finished a similar project for fun and education. It was a 20-year-old codebase from my old game in win32 and DirectX 9. I first ported it to native and also switched to bgfx for rendering. This was the bulk of the work - converting all of the old DirectX fixed function pipeline code to shaders. Luckily all modern shaders can simulate all of the old fixed-function DX pipeline features with little effort. Including the coordinate system. Loading DDS textures didn't present a major challenge either. Had similar native asset loading as yours - no deserializer. It loaded an entire asset file into a preallocated memory block, used packed structures and converted file offsets to pointers after loading. I had to convert it to 64bit for native first. The most surprising thing: I had no idea WASM is 32bit until I read your article! Once I ported to 64bit, I then ported to WASM and I didn't even encounter any arch related bugs. In hindsight I guess it's because most of the original code was 32bit and the asset file format is still 32bit format. When I ported to 64bit I used a deserializer, so I guess that's why it all worked out in the end. For native audio I ended up using SoLoud library, but for emscripten I #ifdef'd it out to use inline JS instead. I figured there is no point in having all that extra audio library code compiling to WASM when modern browsers natively support playing audio, oggvorbis, etc. It worked out ok, but there's still a minor bug where the music doesn't loop perfectly. You can hear a split second gap between end/start. I haven't looked deeply into it yet. Originally when we wrote the game we had banned ourselves from using C++ Exception handling and RTTI. The decision likely paid off as it makes the generated binary smaller and faster. Although I haven't had time to measure. Supposedly C++ exceptions introduce a much heavier overhead in Emscripten. You can see the port in action at https://scorchedplanets.com https://scorchedplanets.com

flohofwoe 4mo ago
> I had no idea WASM is 32bit until I read your article! WASM(32) is a hybrid 32/64 bit architecture. The address range (and thus pointer size) is 32 bits, but it has native 64-bit integers. E.g. it's similar to the Linux x32 ABI. There is also a 'true' 64-bit wasm, but that's still too recent to be used in real-world code: https://caniuse.com/wf-wasm-memory64 https://caniuse.com/wf-wasm-memory64 (but wasm64 doesn't really make sense unless you really need an address space greater than 32 bits, because the downside is slower performance)

fyrn_ 4mo ago

You can get real breakpoints, memory watching, etc in browser with the chrome debugging extension

flohofwoe 4mo ago
I would recommend the VSCode WASM DWARF debugging extension instead of the Chrome extension nowadays: https://marketplace.visualstudio.com/items?itemName=ms-vscode.wasm-dwarf-debugging https://marketplace.visualstudio.com/items?itemName=ms-vscod... This allows to setup an IDE-like 'press F5 to build and start into a debug session' in VSCode, with the debuggee running in Chrome. E.g. see: https://floooh.github.io/2023/11/11/emscripten-ide.html https://floooh.github.io/2023/11/11/emscripten-ide.html
- fyrn_ 4mo ago
  More of a helix user these days. I will look into it though. Thanks for sokol btw, we use it at work for some things. Mainly gfx and the dds encoder

deadbabe 4mo ago

Is it better to render directly in WASM or could you do game logic in WASM and then render in JavaScript with a JS graphics engine?

Panzerschrek 4mo ago

I did the same with one of small games I have developed. It wasn't that hard. I only needed to tweak the build script and to fix some minor issues, like changing how main function works and swapping color components in the result picture. I did use SDL2 for it, but without OpenGL, so, I had no problems with shaders or something similar.

Anais_Elena14 4mo ago

fain

Anais_Elena14 4mo ago

fain big