This is super cool! 10/10 will play more when I can. It's really great seeing the WebAssembly work paying off with such a low barrier to start playing such a polished game.
On Thu, Jan 3, 2019 at 4:33 AM Gabriel CV <[email protected]> wrote: > 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/d3wasm > > Source code: > => https://github.com/gabrielcuvillier/dhewm3-webassembly-port > > This 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 > > > > > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
