June 15, 2026
Small pointers, big drama
Ported my C game to WASM, here's everybug that I hit
One tiny port job turned into a bug circus, and the comments had thoughts
TLDR: A developer’s web port broke because the browser version handled memory differently, causing hidden bugs that never showed up on desktop. Commenters turned the post into a roast-and-help session, debating why the web still works this way while others dropped jokes, nitpicks, and fresh bug reports.
A game developer tried to move their homemade C game from Windows to the web, and what should have been a neat little victory lap turned into a full-blown bug confession booth. The big reveal: the web version thinks smaller. On desktop, some memory addresses are bigger; on the web, they’re smaller, and that mismatch quietly scrambled the game’s saved data. Translation for normal people: the game packed its stuff one way on a computer and unpacked it a different way online, so everything after that went delightfully off the rails. The dev’s survival guide was gloriously practical too: go back to Visual Studio, build a 32-bit version, and debug there instead of suffering in the browser.
But the real show was in the comments, where the crowd instantly split into helpful nerds, baffled skeptics, and chaos goblins. One person delivered the classic “you should’ve written it this cleaner way” lecture, because no coding story is complete without a style-police cameo. Another asked, basically, why is the modern web still stuck acting like it’s 2004? That sparked the hottest mini-debate: should WebAssembly still be using 32-bit pointers when newer 64-bit options exist? Meanwhile, one commenter skipped the engineering talk entirely and announced, "i want to hack 99 night in the forest," which frankly captures the internet’s energy better than any technical deep dive ever could. Even the bug reports got spicy, with someone claiming fullscreen buttons were misaligned in Firefox. So yes, the dev shipped a hard-earned postmortem — but the audience turned it into a mix of debugging clinic, platform roast, and meme theater.
Key Points
- •The article documents issues encountered while porting a plain C game with a custom engine to the web using Emscripten.
- •The main source of bugs was the 32-bit pointer size in the web target, which broke serialized structs containing raw pointers.
- •The developer fixed asset serialization by removing pointers from serialized structs and storing asset byte data separately.
- •A 32-bit native build combined with Visual Studio and AddressSanitizer was used to reproduce and debug WebAssembly-related memory bugs more effectively than browser debugging.
- •The port also exposed a hidden allocation bug and stricter graphics API behavior in the bgfx path using OpenGL ES/WebGL versus Direct3D.