... but yes, surprised how well it ran on my old laptop!
... but yes, surprised how well it ran on my old laptop!
https://groups.google.com/d/msg/emscripten-discuss/pKcWvKppj...
I was having a lot of audio cutouts too, and the framerate tanked when the actions started heating up. Imps jumping around could drop it to the low single digits. Still, pretty impressive for playing in a browser.
It's much harder for apps that are trying to render to the DOM (which is very slow). But WebGL apps should be perfectly fast in browsers...
The reason for the performance penalty with Firefox on Linux is that the framebuffer content is copied from GPU to host memory, compositing is done and then it's copied back to GPU.
For other platforms I'm not sure.
Further, SIMD support has been removed from Javascript and not been added back to WebAssembly yet, so that's another factor 4-8 for computation-heavy code. Experimental pthread support is only available in Chrome experimental for now due to the Spectre and Meltdown exploits. And general GPU compute apparently is really tricky to implement in a secure way, although DOOM does not use it.
Shouldn't happen with GPU compositing in Firefox (layers.acceleration.force-enabled), right?
Can you talk a bit about the biggest problems you faced?
Also, I'm a bit familiar with the doom 3 code, and the loading a 400mb pk4 file issue can easily be fixed by extracting it and loading/streaming the necessary stuff for each level and such.
Getting things working on platforms other than originally intended is really hard. Nice work!