https://github.com/kripken/emscripten/wiki
Sauerbraten was ported, Unreal Engine 3 as well, so, i don't think that DarkPlaces would be too much hassle. Or even ioquake3.
DarkPlaces Javascript
Re: DarkPlaces Javascript
I've ported FTE (demo version at http://triptohell.info/moodles/web/ftewebgl.html ).
(I believe LH spent some time getting DP to run in emscripten also)
There are valid reasons that the unreal port is not considered a serious offering. And it has nothing to do with emscripten's optimisations or javascript performance.
when running in firefox, the game is fillrate limited...
seriously. fillrate limited. fullscreen it drops to 30 fps...
chrome crashes more often than it works (memory fragmentation issues before the game is even running - 64bit versions would fix this but for some absurd reason, browsers are the only major thing that doesn't get official win64 ports).
when chrome DOES work, jsvm bugs run rampant in ways that neither firefox nor opera suffer from.
firefox's jsvm is not exactly bug free either, but at least its bugs are harder to stumble upon.
So if you're making some simple mouse-only game then its fine. If you're porting some complete 3d engine then I wouldn't bother. At least, not if you want to retain compatibility with the detail levels people have come to expect on the desktop.
Anyway, here's the gotchas:
Don't use emscripten's FS stuff. Its not worth your time. (emscripten's sdl includes FS access, so don't use that either).
Even if you dynamically link to gl on other platforms, make sure you exclusively statically link in emscripten. There's no way to get function pointers from emscripten's gl thunks without pulling in inefficient emulation too (or making your own name->pointer function).
Don't use glBufferSubData. You'll destroy any framerates. Do use glBufferData so that you don't need to use client arrays, as those are not supported. This is different from GLES, where vbos are not always supported.
Don't expect it to work on phones. Make a native port instead.
Don't expect it to work in more than one tab at once. You'll go oom in a fragmented 32bit browser memory space when you allocate your power-of-two heap size.
Trim all memory use to the minimum. Avoid large dynamic allocations or anything that can result in heap fragmentation (which means you can use a smaller heap and reduce potential issues at startup).
Mouse grab restrictions are annoying as heck. You can't use escape for anything in your game without annoying the user.
Browsers are just not ready.
But really, the main issue is that of content licensing...
(I believe LH spent some time getting DP to run in emscripten also)
There are valid reasons that the unreal port is not considered a serious offering. And it has nothing to do with emscripten's optimisations or javascript performance.
when running in firefox, the game is fillrate limited...
seriously. fillrate limited. fullscreen it drops to 30 fps...
chrome crashes more often than it works (memory fragmentation issues before the game is even running - 64bit versions would fix this but for some absurd reason, browsers are the only major thing that doesn't get official win64 ports).
when chrome DOES work, jsvm bugs run rampant in ways that neither firefox nor opera suffer from.
firefox's jsvm is not exactly bug free either, but at least its bugs are harder to stumble upon.
So if you're making some simple mouse-only game then its fine. If you're porting some complete 3d engine then I wouldn't bother. At least, not if you want to retain compatibility with the detail levels people have come to expect on the desktop.
Anyway, here's the gotchas:
Don't use emscripten's FS stuff. Its not worth your time. (emscripten's sdl includes FS access, so don't use that either).
Even if you dynamically link to gl on other platforms, make sure you exclusively statically link in emscripten. There's no way to get function pointers from emscripten's gl thunks without pulling in inefficient emulation too (or making your own name->pointer function).
Don't use glBufferSubData. You'll destroy any framerates. Do use glBufferData so that you don't need to use client arrays, as those are not supported. This is different from GLES, where vbos are not always supported.
Don't expect it to work on phones. Make a native port instead.
Don't expect it to work in more than one tab at once. You'll go oom in a fragmented 32bit browser memory space when you allocate your power-of-two heap size.
Trim all memory use to the minimum. Avoid large dynamic allocations or anything that can result in heap fragmentation (which means you can use a smaller heap and reduce potential issues at startup).
Mouse grab restrictions are annoying as heck. You can't use escape for anything in your game without annoying the user.
Browsers are just not ready.
But really, the main issue is that of content licensing...