How I Ported Doom to the Browser with WebAssembly
summary
Ports Doom to the browser by compiling a C# engine to WebAssembly and replacing the nonbrowser parts of managed-doom with a custom SFML replacement. Game logic stays in C# and produces a column‑ordered framebuffer and raw audio buffer that JavaScript draws to Canvas and plays via AudioContext and Canvas using requestAnimationFrame for the loop. Samples are normalized, WADs load in the browser, it hits playable 30–60 fps even on phones, and the prototype takes about one to two weeks of personal work.
AI-written summary · about
chapters (12)
- 0:00Introduction and motivation
- 2:11What is WebAssembly
- 4:40WebAssembly in .NET
- 9:16Game porting explained
- 12:28Choosing Doom for porting
- 13:33Porting strategy and steps
- 18:30Game loop and rendering
- 20:21JavaScript and C# interaction
- 21:24Audio implementation
- 23:07Frame rendering with canvas
- 26:04Live demo of Doom
- 27:35Key takeaways and conclusion
related talks
33mRun your favorite games everywhere with WASM: the BlazorDoom use case
08m#BuildPropulsionLab at #DevoxxUK: @jbaruch with @yostane
56mFrom Hell to Heaven: Porting Doom to MAUI
54mSandbox Games: Using WebAssembly and C++ to Make a Simple Game
56mFrom Hell to Heaven: Porting Doom to MAUI
46mFrom Hell tp Heaven: Porting Doom to MAUI
24mFrom C to Ruby: Porting Doom
01h 09mSandbox Games: Using WebAssembly and C++ to make a simple game