The top sibling parent has the correct explanation, however, I'll expand a bit.

Games prior to Quake were bound to specific O/Ss and/or hardware components.

DOOM was still bound to DOS AFAIK, so it's not portable without significant changes.

Older games are even worse - not only they were bound to DOS, but also to the display adapters of the time (CGA/EGA), which required some sort of emulation (or translation, depending on the approach) in order to be ported.

Games based on the Build engine (written by Ken Silverman), like Duke Nukem 3D and Blood are... simply written in very poor form. Carmack is a tidy programmer, Silverman isn't. Quoting Fabien Sanglard:

> Looking at the innumerable ports that spawned Doom/Quake, I was always puzzled to see so few ports of Duke Nukem 3D. The same question arose when the engine was ported to OpenGL only when Ken Silverman decided to do it himself.

The answer is in his analysis: https://fabiensanglard.net/duke3d/code_legacy.php.

DOOM was definitely made with DOS in mind, but it also ran on NeXT from the beginning. It's pretty portable actually. Since you cited Fabien Sanglard, I guess I should mention that his book about DOOM's source code (Game Engine Black Book: DOOM) explains how the portability stuff (as well as almost everything else) worked in great detail.

Several of us would regularly play it in a Chemistry computer lab on SGI workstations. Annoyed the hell out of the students doing molecular simulations, regrettably.

I really miss one name here: Michael Abrash

John Carmack is awesome. However, to take the next step after Doom, he brought Michael Abrash on board.

> DOOM was still bound to DOS AFAIK

Doom was literally developed on NeXT computers (the precursors to modern Macs, ironic considering Doom was single-handhedly responsible for turning the public perception of PCs from boring office machines to cool gaming systems):

https://en.wikipedia.org/wiki/Development_of_Doom#Programmin...

> DOOM was still bound to DOS AFAIK, so it's not portable without significant changes

DOOM was always extremely portable, the DOS and PC specific parts are well separated from the other code (DOOM was actually developed on NeXT machines, so separating the platform specific parts probably came naturally).

Well, extremely portable, I wouldn't say so.

If you look at the ancestry of SDL2-Doom, for example, there are three ancestors:

- doomgeneric, which seems not simple (https://github.com/maximevince/fbDOOM/compare/master...ozkl:...)

- the above is based on fbDOOM, which is quite simple (https://github.com/maximevince/fbDOOM)

- the above is based on insane-adding-machines/DOOM, which is also not simple (https://github.com/id-Software/DOOM/compare/master...insane-...)

The SDL port itself (https://github.com/AlexOberhofer/sdl2-doom) is definitely not simple.

Porting something that it's not based on a multiplatform library (which is commonly SDL for old game ports) is not an easy task in general.

On SDL, there's an SDL2+minimal ANSI C environment for plan9/9front called NPE.

The SDL2 audio and video libraries are just shims against 9front drawing/audio functions, and often they just work.

Plugging a DOS game to an SDL(2) library won't "just work".

Some concepts are inherent to the hardware and the O/S.

Hardware example: EGA (not the case of doom, but of other, slightly older games) uses bitplanes, it's not just an array of byes; audio cards used specific drivers.

O/S: timers may need to be emulated, as the game may not have a straightforward game loop; due to this, even exiting cleanly may not be trivial to implement.

Not an issue for Q1, it wasn't for neither EGA or VGA for DOS exclusivelly, they had DOS, Windows and Unix versions since day 1.

Quake basically pre-dated hardware rendering on consumer hardware. To a great extent, the consumer 3D accelerator market exists because of Quake. https://fabiensanglard.net/3dfx_sst1/

Aaah the brief, heady days of “no serious gamer would use a hybrid 2D/3D card” and the Voodoo fill rate wars. Fun times!

Voodoo... that's a name I haven't heard in awhile... thanks for that fun memory. Those were interesting times.

Quake and id Software were pioneering things we just take for granted now.

I remember playing QuakeWorld when it came out, on Linux, over a dial up modem. You had ping times of 200-300ms and it was playable. You have to remember at the time Doom and other games were LAN-only. John Carmack used to keep a .plan file with some really cool details behind Quake/QuakeWorld development. Check out Aug 02, 1996 for some detail behind the netcode[1]. You can read the future of gaming being invented right there.

[1] https://github.com/ESWAT/john-carmack-plan-archive/blob/mast...

Yes! SW renderer was one of the reasons I chose that! :-) Also, source code for id tech games is so well written, architected and highly readable.

Blood uses the build engine which was open sourced at about the same time as Quake, there are numerous source ports and it can run on most platforms (although people have gotten it running on mobile devices, there's never been an official port). As nblood is based on eduke32, I'd imagine the only reason it isn't available on more platforms is that no one has volunteered to do it.

Build/Duke was also Ken Silverman's second game. Doom was probably Carmack's 50th

That said, it had some things Doom fans dreamt of, like an interactive level editor that was built into the game engine.

The Build engine's source code isn't enough to port any game running on it, since Build was made as a library (I believe most developers using Build in the 90s didn't have access to the source code).

Also, wasn't there an official Blood port by Nightdive Studios?

It may have been fixed up since but the official ND port had some problems at the time of release (if I remember a civvie11 vid correctly)

edit: just looked it out, it seems this has been address. I'm linking the videos because they're entertaining :D

vid on the original: https://www.youtube.com/watch?v=EkG29e-nE-A

and the patched version: https://www.youtube.com/watch?v=oFUPNlfWiYg

Also, the original build code is extremely hard to read!