Hello,
Here is a port of the Doom 3 video game (idTech 4 engine) to WebAssembly using emscripten. This is based the dhewm3 GPL source port, and on the demo data of the game available for download on the web.
Live demo:
=>
http://continuation-labs.com/d3wasmSource code:
=>
https://github.com/gabrielcuvillier/dhewm3-webassembly-portThis demonstration is using the demo game data, which is roughly 400MB size. I removed DDS compressed textures and the last level of the demo to shrink things down a little bit. But initial loading will be QUITE long, depending on your bandwidth. Game data files are fetched at initial startup and stored persistently for cache reuse.
Things seems to work correctly on several platforms/browsers I tested. The game is playable on modern browsers. It is even working on mobile Android, though not playable due to lack of controls and really bad performance :)
On my system, the Game runs at 20/40 FPS on Chrome, 10/30 FPS on Firefox (don't know why such slower than Chrome), and 1/2 FPS on my mid-class Android mobile phone ;) Note that the native build shows a constant 60 FPS, but it is not using any GL emulation layer!
A few notes:
- Don't expect to have graphics as shiny as the native build, because the port is not using the "shaders" renderer path (using legacy ARB assembly shaders and not GLSL, this is not supported by WebGL), but instead it uses the fixed function pipeline renderer path that was intended for graphic cards without shader support at the time. It does look nice though, with bumpmapping/reflections & co..
- Some visual glitches though (weird looking specular lights on characters), but they are due to the renderer path used and not because of underlying GL emulation library. The issue is the same with a native build without shader support. However, I had to disable some code in Fog rendering because of issues. As so, Fog is now only partially rendered, and sometime glitchy (you may disable it with "r_skipFogLights 1).
- Loading of levels will "hangs" the display. This is due to the way emscripten works with "main loop based" applications, this model does not support well a loop iteration that last for too long (such as loading a level).
- Under the hood, I use the Regal GL emulation layer library, with quite a few tweaks here and then for things to work.
The fixed function pipeline path used by idTech 4 engine use many of the latest enhancements done to OpenGL before the advent of Shaders (GL 1.4 and co, with Texture combiners, DOT3 bumpmapping, Anisotropy, etc.). As so, Regal is doing a great job to emulate fixed function pipeline.
- Like the previous port I did for Arx Fatalis, I had to disable multithreading from the game code, because it is still difficult to make this work with emscripten.
- I did some tests to enable SIMD/SSE2 code path of the engine, but I discovered it is only supported in asm.js and not in wasm. Too bad!
- I still need to update the README file to explain things a little bit more, including how to build the project (not yet 100% straightforward) and package the data.
Feedback / comments welcomed