A somewhat-close port of Chocolate Doom to the browser

Hey guys,

I've been diving into the guts of doom lately, using Chocolate Doom as a reference (initially due to Fabien's glowing praise).

My first goal is just to be able to play Doom II in the browser. Along the way, I've been stripping out bits of code that don't really have an impact on me or my use case.

The readme has a fuller list, and you can also see the full set of commits / file changes I've made (attached a picture of summary).

Right now the biggest changes are

• getting the basic Emscripten (C -> JS/WASM) workflow set up side-by-side with the native builds
• using CMake instead of autotools
• Removing a lot of platform-specific code
• Removing Hexen / Strife / Heretic / etc.

The readme has instructions about how to get it set up to build natively or for the browser. Right now the browser version only gets as far as initializing the music system (first attached image). I'm sure it's not a huge road blocker, I just ran out of time on my flight from Melbourne to Boulder :)

Prior art, for those curious: https://github.com/kripken/boon.

Anyway, I'm quite new to all of this, so I'd love some pointers, or even people just trying out the instructions in the readme to see if the basic build process works.

Oh, and if anyone from the GZDoom team feels like chipping in on how epic a project it would be to port to WebAssembly, please chime in.

Cheers!

1 hour ago, atroche said:

using CMake instead of autotools

Eeeeewwwwww........ *hugs her autotools*

In all seriousness, Doom in a browser is definitely an interesting idea from a technical standpoint.  I'll give it a shot later tonight when I actually have time to sit down and mess with code.

The moment I saw the thread I immediately figured that you were using Emscripten, too :-P

A while back I got Doom sorta working via Emscripten. I had to go back to an incredibly old port called LSDLDoom because it was the only one I could find that used a basically vanilla makefile. https://www.doomworld.com/linguica/emscripten/

Pretty cool to see someone looking at doing this, for me it seems like an obvious direction that's in line with Chocolate Doom's philosophy / goals. I actually did some experimenting with this myself a year or so ago, but didn't get very far. I was planning for this to be my next big project after getting Chocolate Doom 3.x out of the door. It looks like you're doing your own thing (I see you stripped out a bunch of code including the setup tool, ENDOOM, OPL MIDI, etc.) but I might end up cherrypicking some of your changes once I do my project, if they're useful.

With my previous experiments with Emscripten, the major problem I found was that it provides its own implementation of LibSDL that isn't fully compatible with LibSDL and doesn't implement the complete API. That's changed now, since SDL2 now includes a proper Emscripten backend, so just make sure you use that rather than Emscripten's own broken built-in version.

The major change needed to the codebase is refactoring to work in an event-driven way. The code is written with the assumption that it's in control of its own event loop (D_DoomLoop) which you can't do in JavaScript. Other than that I can imagine it being a fairly straightforward port to get up and running. There's further work needed to package it in a nice way and provide a "launcher" that can load IWAD files into in-browser storage etc.

There are so many forks of chocolate that add cmake now that I wonder if this is a relevant data point for the long-standing discussion about adding a cmakefile to the source.

Oh man, chocolate Doom in a web browser = yes please. The Flash version of Doom has been alright but this would be a far better long term solution. If you leave in the ability to connect to existing servers or even define local iwads/pwads that would be even more incredible. Keep up the good work!

I always that GZDoom would be the first one to get a web browser version ;)

In all seriousness, this is cool!

59 minutes ago, Voros said:

I always that GZDoom would be the first one to get a web browser version ;)

Too complex... :P

WebGL is a thing though!

Hasn't an Emscripten-based port of Doom been available since forever?

That went through a lot of adventures, including getting DMCA'd at some point:

What I'd really like to see is a "native" JavaScript port of Doom that can be debugged and inspected on-the-fly using human-readable structures and code that appear close as possible to the original, rather than using a VM intermediary which obfuscates everything, and delegates debugging to the C/C++ back-end, rather than at the browser level where the thing actually runs.

Then there are things like the need to embed file and file-like resources in the "compiled" blob (unless support for reading local files and remote URLs has advanced sufficiently), which is -from a legal standpoint- the major killer of such projects, unless of course you choose to ignore it.