But wasn’t Doom originally developed for “16-bit DOS computers”? That’s the way I originally played it, by installing it from 3.5” floppies as a DOS program on my Windows 3.11 PC, although it was a 486/33 IIRC. I could play the entire game,
save my progress, and I had sound via SoundBlaster. In fact, I even installed Doom II on that same computer.
"System Requirements: PC compatible 386 or greater"
But unofficially, you needed a fast 486 to run it properly. On a 386 you have to switch to low detail mode and/or shrink the view area to get an acceptable frame rate.
I seem to remember having a good time with it on a 386SX 20mhz. If I am remembering correctly (I have about 75% confidence in these memories) I just dialed down the view area by a notch or two which worked well for most of the game until I got to an area with a looot of monsters.
It was pretty tolerable since quicksave and quickloads were so fast. If you stumbled into an area where you took a bunch of damage because your frame rate dropped to 5fps you could just quickload, downsize the viewport, and try again.
What's bullshit about that last one? I had a 386DX40, AMD made them, they were a popular budget option in the early 90s and the first time I played Doom was on that PC. It ran better than that video demonstrates, even at full res, though I ran it half-res and with the window downsized a notch. I presume they're using a particularly crappy video card.
That's about how I remember my 40MHz 386 playing it. At the time, it was mind-blowing anyway. I would usually play it with the window shrunk a couple notches.
One thing I remember was that DOOM did not run well on the 486SX. You needed the 486DX which had an FPU. Maybe there was a 486DX with 33mhz but most were 66mhz I think?
Doom uses fixed point math so it doesn't matter if you have an FPU. But the fastest 486SX was only 33MHz, which isn't really fast enough for Doom, and they were typically used in cheaper systems with slower graphics cards/buses, which also made a big difference.
One of the biggest contributor to performance differences was the implementation of the L2 cache on the motherboard.
More expensive chipsets tended to have better cache implementations... Assuming the system even had cache installed, those cheaper systems often paired a 486SX with a cheap motherboard and zero L2 cache.
When installed on the same motherboard, same cache/memory config, with the same graphics card, same bus speed, a 486SX should run Doom identically to a 486DX.
I remember it being the case that Doom was aggressively tight-loop optimized, so the small amount of L1 cache was more significant especially on clock-multiplied 486s. Though you are right that the SX/DX distinction wasn't meaningful for Doom as it was all done with internet mathematics.
Yeah, the clock multiplier will also make a large difference.
Which might actually be a fair comparison, The DX2 and SX were launched at the same time, so there is a decent chance the "fast 486 DX" someone is talking about is actually a DX2.
The SX2 was launched later, with the same 2x clock multiplier and same size L1 cache, so would preform identically to the DX2 (in non-fpu tasks like doom). But the DX4 was launched at the same time, now with a 3x multiplier and L1 cache doubled to 16KB....
IIRC the fastest base 486 (out of the box without trickery) was 50MHz. There was a DX2-66 (and DX2-50, which ran clock doubled with the rest of the motherboard at 25MHz). There was also the DX4 which despite the name was only click tripled, running as fast as 100MHz of a 33.3MHz. Other manufacturers produced faster clocked i486 compatible processors: I had an AMD 5x86 which was actually quad-clocked, running at 133MHz internally. For tight loops where the code and enough data for a fair few cycles fitted into its on-chip cache (something like 8K code & 8K data?) these were surprisingly speedy compared to Intel's 486s and even low-end (66MHz, and in some artificial tests 75MHz) Pentiums. Cyrix had some similar models that were quicker still for integer work, and IIRC cheaper so even better VFM for sure tasks, but had abysmal floating-point performance which was rapidly becoming pretty important for games around that time.
Doom used integer maths throughout, so would not benefit from and FPU, but did get a boost in complex maps from the faster internal clocks of doubled/tripled/quadded chips. The Quake era (maybe a little earlier for some more niche games like certain fight simulators) is when the FPU became a massively significant factor for home use (though it didn't exclusive use it: the original Pentiums' FPU wasn't trials fast enough so only something like 1/16th of the work was done there and integer approximations starting from those values were used between - improved further by the FPU being able to work on its next bits while the CPU ALUs could do there part, a hack somewhere between pipelining which 486+ units did naturally (& Pentiums more so due to extra ALU circuitry) and hyperthreading).
Hi moderators, please consider not downvoting me here; I'm resorting to commenting in this newer thread where replies are still enabled in an attempt to reach mrob (whose profile has no contact info).
---
Hi mrob,
I just wanted to thank you for your extraordinarily helpful comment about harmonics in music. I've been playing guitar for about 30 years and make regular use of harmonics in my playing (and tuning), but when a nonmusical friend recently asked me to explain why those sounds were so different when lightly touching strings above the 5th, 7th and 12th frets, I had little to offer by way of a coherent explanation. Favorited and bookmarked / added to my PKM. Have a great day and thank you for such a great comment! You're a great example of what makes HN such an awesome community.
IIRC AMD put out a chip that officially ran at 66MHz without clock doubling, though obviously you needed a motherboard (and RAM) capable of running at that rate.
I played it a little in a 386SX40. I had to reduce the rendered screen size, and even then it struggled in open or complex scenes and/or when there were a lot of enemies active.
I thought it was originally developed on 32-bit 68k NeXT workstations, no? I would be interested if there was anywhere to learn how the porting to x86 went, especially with regards to different strategies for block transfers/etc.
It wasn't really "ported", is was developed on NeXTStep, but the target was X86/VGA/DOS"
Apparently they just cross-compiled it. Also, the NeXTStep version of Doom didn't have sound.
"We wrote all of DOOM and Quake's code on NeXTSTEP. We debugged the code in NeXTSTEP with DOOM and Quake's 320x200 VGA screen drawing in a little Interceptor window while the rest of the screen was used for debugging code. When all the code ran without bugs we cross-compiled it for the Intel processor on NeXTSTEP then turned over to our Intel DOS computers, copied the EXE and just ran the game. The DOS4GW DOS-Extender loaded up and the game ran. It was that easy."
In case, like me, you wondered what an "Interceptor window" was:
"NeXT also have an internal kit called Interceptor Kit, which allows a privileged application to punch a hole through the Postscript windowserver directly to the display card."
Id Software's history at that point (commander keen, wolfenstein, catacomb, doom) was entirely on x86 MS-DOS and they were exploiting all the tricks to achieve decent performance for games thought to not be possible on that platform.
So it seems very unlikely (to me) that they would develop the games first for a different platform, using a different OS, on a different CPU, with a different endianness.
They developed Doom on NeXT with highly portable C code. The reason for that is they were more productive on NeXT workstations (development and map design). Doom has been easily ported to every platform because they designed it to be easily ported. Recommended reading: https://fabiensanglard.net/gebbdoom/
Not only that but it was due to their portable software architecture which was by design. Carmack isolated the platform dependent stuff so that you can port it to any other platform without too much effort.
The great majority of platform dependent code is video output, keyboard handling, sound and network.
The functions for that that call dos/x86-specific code are neatly separated by the rest in appropriately named files, so it’s really easy to know what you will need to modify, without a million other distractors.
The difference is that the id devs had already come from the Apple II world first, so they had written plenty of 6502 assembly and were aware of the cycle counting types of optimizations, but chose to give some of them up to use C when they started on x86. That was, at the time, a relatively bold move.
By the time Doom was being made they definitely had a sense of what a high-level approach brought to the table, and that they could focus on just the "hot loops" for micro-optimization when targeting a 386. The process they were using to build their engine was ultimately iterative in nature, building some tools and some rendering and some assets, then gradually pushing each a little further: the introduction of the BSP algorithm came relatively late, for example.
