I'm happy to announce the release of djDoom port with added support for Sigil (1/2) by John Romero. djDoom is pretty much the original vanilla Doom (for DOS) maintained by FrenkelS. Port is compiled with DJGPP (optimized for i386/i486 and i586) and OpenWatcom v2. Code mostly ported from Sakitoshi's MBF204 repository.

Iɴꜱᴛᴀʟʟᴀᴛɪᴏɴ

Do NOT try to use original SIGIL1/2 WAD just as is! Included maps are not optimized for the software drawer but for OpenGL instead (GzDoom). It won't (probably) work anyway. Read further instructions.

Prerequisites:

1. The Ultimate Doom. At least WAD (DOOM.WAD). Please don't use the Shareware version. SIGIL requires Ultimate Doom WAD-file for resources and executable APPVER definition is configured for UDoom also (Doom 1.9 Ultimate).
2. Doom installed on your machine already.
3. SIGIL Megawad. Or SIGIL II Megawad. Free to download at Romero's or you can buy a commercial episode. Both versions tested.
4. Any old DOS machine. IBM PC–compatible. Very high-end i80486 or any newer machine much recommended. DOSBox and 86Box were tested too. 26800 cycles (or more) in DOSBox is recommended for extra chewiness. FreeDOS hasn't been tested but it might work too. i386 version is included but SIGIL will probably resemble a slideshow on any low-end PC. Use with care…as it ain't for sissies! You've been warned.
5. Enough memory available.
   • 640kB of conventional memory for DOS/drivers and DOS extender
   • 1428kB – for executable (WCDOOM.EXE) and a little more for DJDOOM.EXE
   • min. 1440kB free memory for Zone in extended memory area
   • 256kB – after zone in EMA for sound library stuff
   to sum it up, it should be possible to load WCDOOM.EXE on a 4MB memory module, a little more might be required for DJDOOM.EXE because DJGPP is slightly greedier (let's say 5MB). 8MB free memory is recommended and 16MB is upmost optimum. No more than 16MB of RAM is required, because 8192kB is maximum allocation space for the zone anyway.

Installation instructions:

• Simply download binary package, extract it to your DOOM folder and that's it! DO not overwrite any extender (DOS4WG.EXE in particular).
  • DOS4GW.EXE is required by WCDOOM.EXE (Watcom compiler)
  • CWSDPMI.EXE is required by DJDOOM.EXE (DJGPP compiler)
  Both extenders are included in archive (for the sake of having a complete installation package) but no need to overwrite them if already present.
• REName I386DJ.EXE, I486DJ.EXE or I586DJ.EXE to DJDOOM.EXE depending on your CPU architecture.
• Run SETUP.EXE and configure your hardware as usual (config-file is shared between vanilla Doom and DJDoom). Now should be possible to play Ultimate DOOM.WAD.
• Extract and copy SIGIL.WAD (SIGIL_v1_21.wad) or SIGIL2.WAD (SIGIL_II_V1_0.WAD) to the destination folder.
• Download and extract optimized map files. djsigil1.wad or djsigil2.wad should be located next to your executable and the original SIGIL.WAD file.
• Run it:
  • "wcdoom.exe/djdoom.exe -file SIGIL.WAD djsigil1.wad" for SIGIL I.
  • "wcdoom.exe/djdoom.exe -file SIGIL2.WAD djsigil2.wad" for SIGIL II.
  Please pay attention to the order after -file argument.

If everything worked out the way it was supposed to

choose your favorite episode in Nᴇᴡ Gᴀᴍᴇ menu and rest is up to you. If you don't see your favorite episode something went wrong. That's for sure. Or IDCLEV to your favorite map.

Notes:

• As I don't like Software versioning systems too much, consider this more as pre-release version. Not all features from Sakitoshi's repository have been ported (as I don't understand clearly everything but I know what is missing) and there is lot of bugs of course. Play it, test it, and report bugs in this thread. All shall be fixed in near future.
• I recommend trying WCDOOM.EXE before DJDOOM.EXE. Somehow Watcom compiler is able to produce more compact and less crash-prone code than DJGPP. No clue what's behind it. Most crashes can be bypassed just by running WCDOOM.EXE rather than DJDOOM.EXE.
• You may encounter real game-freezes (not just crash) on real hardware or on a period precise emulator. The sound system is to blame. Try -nomus2mid parameter.
• Many thanks belongs to ViTi95, Frenkel, Edward850, dgondos, John Romero for two nice hellish episodes and first and foremost to Gerwin for his mental mentorship. Wouldn't be possible without it. If I've forgotten anyone, please remind yourself. I'm forgetful already.

Wʜᴀᴛ'ꜱ ɴᴇᴡ (Changelog)

• First, it was necessary to raise static limits a bit. I suspected MAXDRAWSEGS=512 segs and MAXVISPLANES=256 vp might be enough. Unfortunately, it's far from enough. So temporary limits have been raised to accommodate 1024 segs and 512 visplanes. I don't like it and still not enough but for the most part you shouldn't meet the infamous visplane overflow so easily.
  The biggest issue is the OG limit (256segs/128visplanes) chosen by John Carmack. This limit was very reasonable for given time period and given hardware. It takes little memory to enlarge both static fields (is just a number) but as usually it takes more CPU time to process bigger list (I believe it's exponential growth or cubic or some mathematical nonsense) so expect lower frame-rate. Unjustified for a given low resolution. So space marines — take your guns, L&L and help me find the right numbers. It's always more welcome to physically optimize the maps than to interfere with the code. I am no mapper, though. I can code, compile and debug stuff and not optimize maps. Dynamic visplane memory allocation, Visplane hashing absolutely possible and have already been discussed.
  • Add switches -devparm -draw256 to draw first 256 segs (OG limit). The rest of the world will be HOM. Theoretically might help to improve performance and skip unexpected visplane overflow.
  • Don't forget to use F5 button (Hɪɢʜ Dᴇᴛᴀɪʟ/Lᴏᴡ Dᴇᴛᴀɪʟ) where appropriate. It still works best.
  • "R_FindPlane: no more visplanes, overflow at coords x:%i, y:%i, height: %i" coordinates of visplanes overflow added. Might be useful for mappers.
• Dots replaced by nice frame-rate counter:
  
  Simply add -devparm parameter, it will pop-up.
• -nomus2mid parameter already mentioned. Used to skip on-the-fly conversion form MUS to MIDI format. Ought to be used against softlocks on real hardware.
• -cdrom fixed, -novideo, -nosound fixed. Shall work how intended now.
• Few little bug fixes I don't remember already.

• Grunt, I need you to implement this and that (640x400) and whatever function/feature into engine/this port.
  • It won't happen. I like it vanilla. Actually, I would like to take my time and throw away a few things I consider redundant.
• Oh, come on… Don't be a jerk!
  • Do it yourself. There is already a plethora of ports engaging in feature creep trends. DJDoom is pretty much vanilla. The compressed WCDOOM.EXE binary has size of 137KiB and I sincerely believe it could and should get as close to 100kB as possible. 99kB executable and all work is done. I would love to remake/reimplement few things myself, though.
• Like what?
  • DMX library rather than APODMX, if ever to be released by Paul Radek. And maybe optimization of the DOS assembly module as throughput through slow ISA bus is a bigger bottleneck than anything on 386-class machines. Unfortunately, this level of sorcery is out of my league.
• I think I've found a bug:
  
  • Not a bug. As already mentioned, I'm not mapper. My idea of map optimization is to cut away things (in Doom Builder) unnecessary for gameplay. Smaller BSP tree to process, right? Result is hole in the world (HOM). Some mappers specialized in map optimizations seriously wanted. I can supply software, not the maps.
• Grunt, you need GitHub!
  • I don't think so. Give me a better (retro) alternative.
• I've got sound issue!
  • Blame APODMX, don't blame me. I love PC-Speaker. 😉
• Can I use DJDOOM/WCDOOM for something else? Other WADs or total conversions…
  • Sure. As long as it fits your memory and static limits…enjoy your retro.
• Why so many different files?
  • Licensing issues.
• Under what license are attached WAD files released?
  • It's complicated.
• What took you so long?
  • Honestly, putting something together and publishing it as one package it's a lot more work than I originally anticipated. Never ever again.
• So why now?
  • I need to clean my disk drive before I can move my time and care to a different engine. So called "engine++".
    

Sᴏᴜʀᴄᴇ ᴄᴏᴅᴇ

Attached according to GPL license. Included COMP[DJ/WC/OC/WC].BAT never worked for me. But there is Makefile included (Makefile.wc for Watcom) so simply edit to fit your custom preferences and run make command. Tested in DOS environment (DJGPP, default Makefile), tested in Windows and cross-compilng on any Linux distro for DOS platform should work as well. DJDOOM is much better suited for debugging. However, OpenWatcom produces much more compact and predictable code. Use as you like.

-Grunt