Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

A somewhat-close port of Chocolate Doom to the browser

Recommended Posts

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.




Screen Shot 2017-07-29 at 1.03.25 pm.png

Screen Shot 2017-07-29 at 1.41.42 pm.png

Share this post

Link to post
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

Share this post

Link to post

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.

Share this post

Link to post

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.

Share this post

Link to post

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!

Share this post

Link to post

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

In all seriousness, this is cool!

Share this post

Link to post
59 minutes ago, Voros said:

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


Too complex... :P


Share this post

Link to post

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.

Edited by Maes

Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now