WAD Commander and wasm-doom

[lazarv]

7 years after creating the HTML5 version of Wolfenstein 3D, I started to work on an online tool to play DOOM® and DOOM II® in the browser or as a progressive web app (on mobile and on supported desktop OSs). The MVP version of WAD Commander is now available on wadcmd.com.

 

My development of a Doom engine for the browser started years ago. I experimented with an engine using CSS 3D after wolf3d (had a working engine for it, but performance was awful) and a full rewrite in JavaScript using WebGL by creating a converter for the maps from 2D to 3D. The later was very promising, but I had no time to finish it. Finally when WebAssembly became a real option to create online apps, I was able to run Doom properly in a browser.

 

There was an original port of Doom to HTML5 using asm.js in 2011 by Alon Zakai, but that version was taken down and as I remember it was also not perfect and contained bugs because the browser was not ready and mature enough to run it. Since then, multiple more advanced games were ported to run in the browser, like Quake 3 or Doom 3 lately, but I wanted to stick to the original Doom. I think Doom is the ideal game right now to run in browser or on mobile. The newer games are too heavy in size and performance need for a good user experience. Now with all major browsers supporting WebAssembly I was able to create a port of Chocolate Doom with very good results. All things should work the same as the original version. The results were very good, the game ran on low-end mobiles very well too.

 

I chose Chocolate Doom as a base because that is the most vanilla-compatible source port and it's using the SDL library. First I modified it to build successfully using Emscripten as a WebAssembly binary. I dropped the parts that doesn't make sense in the browser, this includes the networking parts, so currently there is no multiplayer support. I added support for music packs by creating a new music module using Web Audio API, but it has a fallback to OPL music (the OPL synthesizer was too heavy for some low-end devices). Also added a bunch of browser events for integration purposes. Source code for wasm-doom is available on github.

 

Then I started creating WAD Commander which is basically a launcher using wasm-doom. You can drop or browse for your .wad and .deh files and start the game with those. At this point to support more PWADs I integrated the limit-removing parts from Crispy Doom into wasm-doom. Your files will be also stored locally in the browser so you have to do this only once for each file. I plan to constantly and regularly update WAD Commander with new features and upgrades as I have time for that beside my daily work. You can support this on Patreon, see details on the site.

 

All suggestions and review are very welcome!

Please visit wadcmd.com, thanks!

[Hellbent]

I forgot how bad the original doom graphics were. Ports sure have taken the game a long way! I also forgot that you couldn't change the controls within the game, and that you had to load a separate setup.exe to do it. One odd thing I noticed in the credits after fumbling around a bit with the original controls: Mike Abrash is listed as one of the lead programmers, but I've never heard his name dropped in association with Doom. Wikipedia shows that he worked on Quake, but makes no mention of Doom. Why is his name listed in the UDoom credits so prominently? His name is listed right after John Carmack and before John Romero under "programming".  The only thing I can reason is they did that because at the time of UDoom's release he was a member of id Software as a lead programmer on Quake, since by that time Quake would have been in full swing.

[Dark Pulse]

1 hour ago, Hellbent said:

I forgot how bad the original doom graphics were. Ports sure have taken the game a long way! I also forgot that you couldn't change the controls within the game, and that you had to load a separate setup.exe to do it. One odd thing I noticed in the credits after fumbling around a bit with the original controls: Mike Abrash is listed as one of the lead programmers, but I've never heard his name dropped in association with Doom. Wikipedia shows that he worked on Quake, but makes no mention of Doom. Why is his name listed in the UDoom credits so prominently? His name is listed right after John Carmack and before John Romero under "programming".  The only thing I can reason is they did that because at the time of UDoom's release he was a member of id Software as a lead programmer on Quake, since by that time Quake would have been in full swing.

IIRC Carmack (and possibly others) have gone on record as to say that while Abrash didn't work on Doom directly, they relied so heavily on his books and treated them like gospel that they felt that if they hadn't read them, Doom wouldn't exist.

 

That, along with the fact he was indeed at id during Ultimate Doom/Quake's development, is why he got credited.

 

Doom Wiki's got an article on him.

[THEBaratusII]

 

Ah nice! It plays pretty well, I do have a couple feature suggestions

 

First of all, we,ll need reconfigurable controls (Some don't prefer the arrow keys :P ). And second, bringing multiplayer from 2 to 4 players, which would be cool to have.

[-TDRR-]

10 hours ago, Baratus II said:

bringing multiplayer from 2 to 4 players, which would be cool to have.

I don't think that's easy at all, considering how this is set up. In fact, all the networking code was removed from this port.

 

Sadly the performance is much worse than with the flash version, otherwise this is a really good port.

[fraggle]

Good stuff. I'd be happy to see some of your changes merged upstream into Chocolate Doom - as far as I'm concerned, HTML5 is "just another platform" that Chocolate Doom ought to run on, and I'd personally like us to get to a point where all source ports run in the browser and aren't the domain of "specialized" ports.

 

Don't be too quick to disregard multiplayer either - with modern stuff like WebSockets I suspect it's probably even possible to make that work.

 

Something strange is going on with the screen scaling for me - I don't know if this is just a Linux thing.

[boris]

3 hours ago, -TDRR- said:

Sadly the performance is much worse than with the flash version, otherwise this is a really good port.

Hmm, performance seems pretty normal for me, for having a capped frame rate.

 

35 minutes ago, fraggle said:

Something strange is going on with the screen scaling for me - I don't know if this is just a Linux thing.

Doom Guy: Battle Angel

[lazarv]

Thanks to all of you for the likes and comments so far! :)

 

18 hours ago, Baratus II said:

 

Ah nice! It plays pretty well, I do have a couple feature suggestions

 

First of all, we,ll need reconfigurable controls (Some don't prefer the arrow keys :P ). And second, bringing multiplayer from 2 to 4 players, which would be cool to have.

 

Thanks! WAD Commander will evolve and new features will be regular, including configuration file setup, like changing controls. I would like to also implement multiplayer later, but it will use web tech, that's why I dropped the original network code.

 

8 hours ago, -TDRR- said:

I don't think that's easy at all, considering how this is set up. In fact, all the networking code was removed from this port.

 

Sadly the performance is much worse than with the flash version, otherwise this is a really good port.

 

What .wad files and what type of device did you use when you experienced slow performance? For me on desktop and iPad/iPhone it runs smoothly using nuts.wad, but my older Samsung S7 struggles with that map too, but running smoothly on normal maps.

 

4 hours ago, fraggle said:

Good stuff. I'd be happy to see some of your changes merged upstream into Chocolate Doom - as far as I'm concerned, HTML5 is "just another platform" that Chocolate Doom ought to run on, and I'd personally like us to get to a point where all source ports run in the browser and aren't the domain of "specialized" ports.

 

Don't be too quick to disregard multiplayer either - with modern stuff like WebSockets I suspect it's probably even possible to make that work.

 

Something strange is going on with the screen scaling for me - I don't know if this is just a Linux thing.

 

I'm already using the limit-removing rendering code from Crispy (only to support more PWADs, not the fancy stuff), I think it's not mergeable anymore. Also I'm planning to implement Boom-engine features for same reason. But yes, with a bunch (a lot?) of conditional macros it's doable to build from Chocolate with target set as Emscripten/WebAssembly. I chose the easier way and modified the code where it was needed. My most important modification was that I changed the runtime loop to be async, including modifications on screen update (wipe parts), but also disabled/removed window handling and such.

 

I really want to return to the implementation of multiplayer mode, I think WebRTC (in which solution WebSocket is used in signaling server) is a more appropriate technology for this. It's hard to do it properly and a lot of async code needed and also more web UI for establishing connection between players. It's easier for C/C++ developers, using sync code almost anytime. :)

 

I fixed the scaling/aspect ratio bug, thanks for pointing that out! Doom guy has a normal face now. :)

[-TDRR-]

50 minutes ago, lazarv said:

What .wad files and what type of device did you use when you experienced slow performance? For me on desktop and iPad/iPhone it runs smoothly using nuts.wad, but my older Samsung S7 struggles with that map too, but running smoothly on normal maps.

It was just the browser, Firefox is slow with it but Chrome ran okay.

[Caco is PAIN]

I know this is old but for me whenever trying to load in a WAD, it gets stuck on the "Please Wait" screen. Help needed here!

[DU0]

On 4/8/2022 at 12:14 PM, Caco is PAIN said:

I know this is old but for me whenever trying to load in a WAD, it gets stuck on the "Please Wait" screen. Help needed here!

Did you try refreshing the page? Here it froze on my the first time I tried running my own .wad (which is 10Mb in size), but worked on the second try after 10 seconds or so.

 

Also (and unrelated), did anyone manage to compile this from source?

[Caco is PAIN]

54 minutes ago, DU0 said:

Did you try refreshing the page? Here it froze on my the first time I tried running my own .wad (which is 10Mb in size), but worked on the second try after 10 seconds or so.

 

Also (and unrelated), did anyone manage to compile this from source?

Yeah, now it works! Thank you very much!

To your question, no, I don't think so. I really wish though as Hexen/Heretic can then be included :/

[Caco is PAIN]

On 2/21/2019 at 5:57 AM, lazarv said:

7 years after creating the HTML5 version of Wolfenstein 3D, I started to work on an online tool to play DOOM® and DOOM II® in the browser or as a progressive web app (on mobile and on supported desktop OSs). The MVP version of WAD Commander is now available on wadcmd.com.

 

My development of a Doom engine for the browser started years ago. I experimented with an engine using CSS 3D after wolf3d (had a working engine for it, but performance was awful) and a full rewrite in JavaScript using WebGL by creating a converter for the maps from 2D to 3D. The later was very promising, but I had no time to finish it. Finally when WebAssembly became a real option to create online apps, I was able to run Doom properly in a browser.

 

There was an original port of Doom to HTML5 using asm.js in 2011 by Alon Zakai, but that version was taken down and as I remember it was also not perfect and contained bugs because the browser was not ready and mature enough to run it. Since then, multiple more advanced games were ported to run in the browser, like Quake 3 or Doom 3 lately, but I wanted to stick to the original Doom. I think Doom is the ideal game right now to run in browser or on mobile. The newer games are too heavy in size and performance need for a good user experience. Now with all major browsers supporting WebAssembly I was able to create a port of Chocolate Doom with very good results. All things should work the same as the original version. The results were very good, the game ran on low-end mobiles very well too.

 

I chose Chocolate Doom as a base because that is the most vanilla-compatible source port and it's using the SDL library. First I modified it to build successfully using Emscripten as a WebAssembly binary. I dropped the parts that doesn't make sense in the browser, this includes the networking parts, so currently there is no multiplayer support. I added support for music packs by creating a new music module using Web Audio API, but it has a fallback to OPL music (the OPL synthesizer was too heavy for some low-end devices). Also added a bunch of browser events for integration purposes. Source code for wasm-doom is available on github.

 

Then I started creating WAD Commander which is basically a launcher using wasm-doom. You can drop or browse for your .wad and .deh files and start the game with those. At this point to support more PWADs I integrated the limit-removing parts from Crispy Doom into wasm-doom. Your files will be also stored locally in the browser so you have to do this only once for each file. I plan to constantly and regularly update WAD Commander with new features and upgrades as I have time for that beside my daily work. You can support this on Patreon, see details on the site.

 

All suggestions and review are very welcome!

Please visit wadcmd.com, thanks!

Is there a version of wadcmd that has Heretic/Hexen?