watlings VS doom-sokol

If we’re doing self promo, I’ve got something similar but significantly smaller in scope:

https://github.com/EmNudge/watlings

It credits Rustlings at the end of the page linked to (https://github.com/EmNudge/watlings#credits).

Doom is actually quite easy to build because the source code is already structured to keep the platform-specific parts isolated (Doom was developed on NeXT workstations and then 'downported' to DOS.

For instance here's my WASM port of the Doom shareware version. This is a fork of doomgeneric, which itself is a fork of fbDoom - but midway through I noticed that all the abstractions added by fbDoom and doomgeneric are actually not very helpful for a WASM port that should run in browsers, and that I probably would have been better off forking the original source instead):

Github repo: https://github.com/floooh/doom-sokol

Hosted version: https://floooh.github.io/doom-sokol/

Here are a couple of real-world examples, these are all C/C++ code bases which run across Linux, macOS, Windows, iOS, Android and in browsers without porting:

Home computer emulators: https://floooh.github.io/tiny8bit/

CPU simulators for Z80 and 6502:

https://floooh.github.io/visualz80remix/

https://floooh.github.io/visual6502remix/

The shareware version of Doom:

https://floooh.github.io/doom-sokol/

Samples for the cross-platform libraries this stuff is built on top: https://floooh.github.io/sokol-html5/

WASM (and asm.js before it) turn the web into "just another platform" for cross-platform code bases written in any language that can compile to WASM, and that's pretty great.

I started my WASM DOOM port (https://floooh.github.io/doom-sokol/) from doomgeneric which was helpful at first, but since I had to 'slice' the various modal loops in Doom in order to make it work in a frame-callback app model it wasn't all that helpful in the end unfortunately.

My porting notes for anyone interested: https://github.com/floooh/doom-sokol#porting-notes