Brutal Doom in the browser, booting straight into the map
A fork of a UZDoom WebAssembly port that boots one game the moment the page loads. Open the URL on a TV and you are in MAP01.
There is a WebAssembly port of UZDoom that runs in a browser, and it is good. It has a picker where you upload an IWAD, drop in mods, and press Launch. I wanted something narrower. Open a browser on the TV, and Doom 2 with Brutal Doom is already starting.
So this fork is a container you point at a directory of WADs, and it boots one game.
Boot config
The fork adds a boot.json next to the WADs:
{ "iwad": "doom2.wad", "file": "brutal22test6.pk3", "warp": 1, "skill": 4 }With that in place, visiting the address loads Doom 2 with Brutal Doom and drops into MAP01 on Ultra-Violence, skipping the menu. The first visit downloads the WADs with a progress bar. After that they live in the browser's IndexedDB and the game starts immediately. Drop another file in the mounted directory and it is loadable by name, with no registration step.
URL parameters override the file, so a shared link with ?warp=7 still works on a kiosk deployment. Every parameter is checked against a strict pattern before it goes near the engine, and anything that does not match is dropped.
The bug I fixed
Upstream ships Brutal Doom's damage overlays disabled, because they covered the screen in near-opaque red. The cause was a HUD message cap applied per font. Brutal Doom draws damage with about twenty different graphics over the same pixels, so a cap of four per font still allowed roughly eighty stacked translucent layers. Capping them all together fixed it, and the overlays are back on.
The two settings that kill it
WebAssembly threads need SharedArrayBuffer, and browsers only provide that on a page that is cross-origin isolated and served from a secure context. Miss either one and the engine's threads never start.
- The bundled Caddy sets
Cross-Origin-Opener-Policy: same-originandCross-Origin-Embedder-Policy: require-corp. If you put your own reverse proxy in front, both headers have to arrive at the browser untouched. - It has to be HTTPS. A plain-HTTP LAN address is not a secure context, and the engine will refuse to start there. Plain HTTP works only on
localhost.
The fork also builds on Linux and macOS, where upstream's helper tools only shipped as Windows binaries. WADs are not included. Bring your own.
