If you knew what was going on under the hood, yeah it's very impressive. Taking a fixed-pipeline shader based game and porting it to modern WebGL isn't easy.

I don't know how this port is doing it, but with emscripten it might be as easy as adding the `-s LEGACY_GL_EMULATION=1` compile flag.

The author used Regal rather than the LEGACY_GL_EMULATION feature in Emscripten, which I doubt was complete enough as Doom 3's fixed-function pipeline was easily one of the most demanding OpenGL 1.x games. Anyway, I don't think it's particularly valuable criticizing how hard or not-hard the effort was when the end result is novel and impressive.

One of the difficult thing was not knowing during the whole porting process if in the end it would really work, or not... I almost gave up several time :)

I used to develop an emulator. Different scope, but I guess there are a lot of similarities, so I feel your pain.

Getting things working on platforms other than originally intended is really hard. Nice work!

How long did it take to port?

First commits on the repos (D3 and Regal) are from 17/12. I started to work on this a week or so before the first commits, so it took roughly 4 weeks, with daily progress and commits. In the end the amount of changes in the code is relatively small. Time was mostly spent investigating and figuring out WHAT changes needed to be done for things to work

Impressive man!

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.

I am preparing a Readme file with more explanations. Yes I think I think I'll extract everything on the server, and implement some form of lazy loading thanks to some emscripten mechanism

from pasts experiences a porting a moderate codebase(300k) is not quite fire and forget with emscriptem, but had no idea of that flag(last attempt a couple of years ago, didn't follow on changes)

Getting something like this running in a web browser at acceptable performance is a significant technical achievement.

Is it? Web browsers aren't that much slower than native (around 2x with web assembly and WebGL I think).

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...

All WebGL implementations have significant overhead compared to native GL. For example, just clearing the screen at 60 fps taxes my CPU at 10% on Windows (30% on Linux) while a C program that does the same uses 0% CPU.

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.

> copied from GPU to host memory, compositing is done and then it's copied back to GPU

Shouldn't happen with GPU compositing in Firefox (layers.acceleration.force-enabled), right?

It has been years that we have WebGL running in the browser, not to mention Linux kernel ect ...

Hardware acceleration in Linux? someone pinch me, I'm dreaming.

I'm talking about running Linux in the browser:

https://bellard.org/jslinux/