igdoom: Experimental Doom fork written in / ported to Zig

WARNING: I haven't sorted out the GPL licensing compliance stuff yet - there's missing licence texts in a bunch of files. You should assume all *.zig files are under GPLv2-or-higher except for any build.zig files which I (GreaseMonkey) release into the public domain.

How does one use this thing?

You will need Zig 0.11.0 to build this.

As a fork of the original Linux source code release (with the 1999 GPLv2+ relicensing), you will need development libraries for Xlib, Xext, and libnsl. You will also probably need ALSA development libraries (libasound), unless you want to change some settings for the sound server to use OSS.

Using Windows? After all the changes that were done to 10 and 11: Why?

(there will be GDI support when I get around to it)

Engine changes

• Port a bunch of stuff to Zig
  • As an added bonus, when this crashes you get a backtrace with source code file+line+col information
• Make it work on 64-bit
• Use ALSA instead of OSS for sound
  • OSS was working with aoss, but only in a 32-bit build. Porting it to ALSA was easier than I expected.
  • The OSS code should still be there and maybe functional with the appropriate build flags
• Added 16bpp and 24bpp rendering support, both with scaling (Zig made this easy, C++ would also do the same)
• Preliminary unused support for higher resolutions (I mean, it works, but it's not the default)
• Various limits lifted:
  • MAXDRAWSEGS
  • MAXINTERCEPTS
  • MAXOPENINGS
  • MAXSEGS (this was rewritten to track open spaces instead of blocked spaces, which ends up being easier to understand)
  • MAXVISPLANES (note: if you don't want to lift this limit in your own engine, you can always just make it not crash as per what happens with a drawsegs overflow)
  • MAXVISSPRITES
• Partial UMAPINFO support - if it's valid, it should at least parse, but the presence of this lump assumes you don't want any other maps
• Linedef special handling is done declaratively
• Partial Doom-in-Hexen map support - primarily based on the ZDoom wiki and sticking mostly to what's only needed for Doom, but happy to get a few other niceties in there
  • Doing Doom-in-Hexen allows for quite a bit of flexibility without kludging in yet another pile of linedefs.
  • Not sure if I'll shove ACS and/or Polyobj in later. Knowing that I'm working on getting slopes working, I suspect they're going in anyway.
• All in-WAD acceleration structures (NODES, SEGS, SSECTORS, BLOCKMAP, REJECT) removed and replaced with dynamic acceleration structures
  • nuts.wad works great on my machine (THINGS are tracked in a quadtree, LINEDEFS are a TODO)
  • gothic99.wad works great on my machine (segs generated from linedefs, then topological sorting is performed via a "front buffer" - think of a "z buffer" but indicating which seg is in front at a given spot)
  • ...OK, my machine uses a 7950X3D CPU. But trust me, getting everything to work at 35 FPS required effort!
  • There are a couple of extra flags for messing around with this, try -speen (spins the map) or -dentist (player pushes vertices around). Will probably desync on a net game.
  • Note that if you're out of bounds, you get treated as being in sector 0.
• Experimental support for slopes
• Lightmap dithering (currently for planes only, segs are a TODO)
• Mip-mapping (currently for planes only, segs are a TODO)

Be aware that there are bugs.

Also, you will definitely need more RAM than what Doom normally needs. But if you're reading this on a modern web browser, you will be fine. (And if someone mirrors this to GitHub, you can probably close that tab and then proceed to run 10 instances of this at once.)