| ▲ | hexer303 3 hours 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 | ||
| ▲ | flohofwoe 3 minutes ago | parent [-] | |
> 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 to recent to be used in real-world code: 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) | ||