Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The memory64 proposal was merged into upstream last year, any reason to opt into 32 bit despite that?
    by xydone
  • 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.
    by Panzerschrek
  • 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?

    by Someone
  • 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.
    by unwind
  • 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.

    by thewavelength
  • 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.
    by arcadialeak
  • 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

    by hexer303
  • 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.
    by diath

Explore Birbla archives