A while back I was making a collection of installable DOOM games for a CD, but needed a DOOM engine to go with them. There were several complications, including DeHACKed support (games that worked by dynamically patching the DOS DOOM executable), sound support, the ability to run network games between Solaris (SPARC and x86), Linux (SPARC, x86 and MIPS), Windows-NT through Vista, AIX, NetBSD (SPARC, x86, MIPS, et al) and so on. There are many DOOM engines out there, but the vast majority of them have their own unique extensions and non-compatibilities with generic DOOM PWADs.
No, I don’t need OpenGL acceleration (seemed like this was originally done just to see if it could be, not because it was really needed), nor do I need room-over-room full-3D extensions, working or otherwise, and 3D sound clips are not strong on my list. It’s only DOOM, for goodness sake!
Also, the original DOOM engine for DOS sent raw C structs in native byte-order over the wire for net games, which meant that the semi-official computer-manufacturer-sponsored ports (sundoom for SPARC) could not be networked with any x86 DOOM. The Silicon Graphics’ version, sgidoom had another problem: it was binary only and compiled for the R4000 processor, so would not work on my Indigo-R3000 system: fortunately, the Irix Development Option software for Irix 5.3 includes a utility program that can convert 32-bit R4000 binary executables directly into R3000 binary executable files, by replacing the R4000-only op-codes with sequences of older op-codes, and is smart enough to know how to redjust all the relocation information. Funky!
I spent ages investigating a whole slew of DOOM engines: linuxdoom, BOOM, PrBOOM, ZDOOM, et al, et al.
No joy: either they were binary-only (so I couldn’t build on SPARC, or adapt the network code to be fixed-byte-order-and-padding), or had so many extensions to not be recognisable as DOOM any more, or absolutely *required* fancy hardware such as DirectX7 video card, special keyboards, or even no keyboard(!), and what have you.
Eventually, I *did* find a suitable candidate: Chocolate DOOM, a rewrite designed explicitly to have the classic DOOM look and feel. Being based on the Simple DirectMedia Layer (SDL) library for drawing, audio, input and networking, it was also very portable (not to DOS unfortunately, but I figured a minimum x86 platform of Win32 wasn’t cutting too many people off).
Apart from a minor compiler-portability issue with the SDL-1.11 sources (for which I sent a patch to Sam L who incorporated it into SDL-1.12), Chocolate DOOM was easy to build for Solaris and Linux; the Windows versions are available pre-built so I didn’t need to build those. On Windows, SDL can use DirectDraw or plain old Windows GDI (automatic), so portability to older Windows hardware was a given. On the UNIX side, SDL uses plain old Xlib by default, so no X extensions are required. Chocolate DOOM also has built-in DeHACKed emulation, auto-detection of and support of DOOM, DOOM-II and Ultimate-DOOM PWADs, so I did not have to wave goodbye to what otherwise would have been DOS-only PWADs.
All in all, it worked beautifully, see the evidence.
Playing many of the DOOM games on a 472-MHz Sun Ultra-10 with built-in PGX24 PCI graphics showed some signs of visible screen-tearing (slow video updates), *but* on a 180MHz SPARCstation-10 with a 1993-vintage 24-bit RasterFlex SBus graphics card was fine, even with other tasks running in the background), and was fine on a 60 MHz SPARCstation-20 with an SBus 8-bit GX card.
Seems that the PGX24 (ATI RagePro) built-in to the later Ultra-5 and Ultra-10 workstations is either dog-slow, or *really* does not like running in 8-bit mode. Using a TechSource Raptor-GFX8P PCI graphics card in the Ultra-10 made everything alright, so that is what I am using in my Ultra-10 now and forever more – unless I can get my hands on a vertical Creator-3D UPA card, of course!