9 ms·

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

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.

sjm-lbm 3y ago
Doom used a DOS 32 bit extender called DOS/4GW: https://en.wikipedia.org/wiki/DOS/4G https://en.wikipedia.org/wiki/DOS/4G.
deleted 3y ago
[deleted]
nxobject 3y ago
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.
- sillywalk 3y ago
  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." http://web.archive.org/web/20140310124554/http://rome.ro/2006/12/apple-next-merger-birthday.html http://web.archive.org/web/20140310124554/http://rome.ro/200...
  - wk_end 3y ago
    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." https://www.paullynch.org/NeXTSTEP/NeXTSTEP.TechReview.html https://www.paullynch.org/NeXTSTEP/NeXTSTEP.TechReview.html
- tredre3 3y ago
  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.
  - deleted 3y ago
    [deleted]
  - tom_ 3y ago
    That is exactly what they did. It's discussed in the Masters of Doom book, as I recall.
  - syntheweave 3y ago
    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.
  - xcv123 3y ago
    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/ https://fabiensanglard.net/gebbdoom/
    - bombcar 3y ago
      It is the highly portable cross-system C code that makes it so easy to run doom on everything. Because they were running ut on such different systems, almost all porting bugs were caught in development.
pavlov 3y ago
The 486 is a 32-bit CPU, like the 386 before it. Doom’s official minimum system requirement was a 486/66MHz.
- mrob 3y ago
  Mobygames has a scan of the packaging: https://www.mobygames.com/game/1068/doom/cover/group-1549/cover-3354/ https://www.mobygames.com/game/1068/doom/cover/group-1549/co... "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.
  - JohnBooty 3y ago
    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.
    - justsomehnguy 3y ago
      Only if you somehow time traveled and brought a FAST DOOM source port with you. 386SX 20MHz no cache: https://youtu.be/osgld_uynl8?t=95 https://youtu.be/osgld_uynl8?t=95 486SX 8KB cache: https://youtu.be/osgld_uynl8?t=151 https://youtu.be/osgld_uynl8?t=151 386DX 40MHz 8MB RAM: https://youtu.be/9_2qGaIOvjs https://youtu.be/9_2qGaIOvjs 386DX 33MHz 8MB RAM ET4000: https://youtu.be/KQDEKoRcXZc?t=140 https://youtu.be/KQDEKoRcXZc?t=140 386DX 40MHz 4MB RAM 256KB cache (probably bullshit), full viewport: https://youtu.be/L6U8fyEgRH4 https://youtu.be/L6U8fyEgRH4 Notice how it's fine in the corridors but starts to lag at any open space. There was a reason DOOM/2 got it map design.
      - JohnBooty 3y ago
jezze 3y ago
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?
- feiss 3y ago
  I played Doom in my 486sx 25mhz..
  - dspillett 3y ago
    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.
- mrob 3y ago
  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.
  - phire 3y ago
    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.
    - dspillett 3y ago
      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.

sjm-lbm 3y ago

Doom used a DOS 32 bit extender called DOS/4GW: https://en.wikipedia.org/wiki/DOS/4G https://en.wikipedia.org/wiki/DOS/4G.

deleted 3y ago

[deleted]

nxobject 3y ago

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.

sillywalk 3y ago
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." http://web.archive.org/web/20140310124554/http://rome.ro/2006/12/apple-next-merger-birthday.html http://web.archive.org/web/20140310124554/http://rome.ro/200...
- wk_end 3y ago
  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." https://www.paullynch.org/NeXTSTEP/NeXTSTEP.TechReview.html https://www.paullynch.org/NeXTSTEP/NeXTSTEP.TechReview.html
tredre3 3y ago
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.
- deleted 3y ago
  [deleted]
- tom_ 3y ago
  That is exactly what they did. It's discussed in the Masters of Doom book, as I recall.
- syntheweave 3y ago
  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.
- xcv123 3y ago
  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/ https://fabiensanglard.net/gebbdoom/
  - bombcar 3y ago
    It is the highly portable cross-system C code that makes it so easy to run doom on everything. Because they were running ut on such different systems, almost all porting bugs were caught in development.

pavlov 3y ago

The 486 is a 32-bit CPU, like the 386 before it. Doom’s official minimum system requirement was a 486/66MHz.

mrob 3y ago
Mobygames has a scan of the packaging: https://www.mobygames.com/game/1068/doom/cover/group-1549/cover-3354/ https://www.mobygames.com/game/1068/doom/cover/group-1549/co... "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.
- JohnBooty 3y ago
  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.
  - justsomehnguy 3y ago
    Only if you somehow time traveled and brought a FAST DOOM source port with you. 386SX 20MHz no cache: https://youtu.be/osgld_uynl8?t=95 https://youtu.be/osgld_uynl8?t=95 486SX 8KB cache: https://youtu.be/osgld_uynl8?t=151 https://youtu.be/osgld_uynl8?t=151 386DX 40MHz 8MB RAM: https://youtu.be/9_2qGaIOvjs https://youtu.be/9_2qGaIOvjs 386DX 33MHz 8MB RAM ET4000: https://youtu.be/KQDEKoRcXZc?t=140 https://youtu.be/KQDEKoRcXZc?t=140 386DX 40MHz 4MB RAM 256KB cache (probably bullshit), full viewport: https://youtu.be/L6U8fyEgRH4 https://youtu.be/L6U8fyEgRH4 Notice how it's fine in the corridors but starts to lag at any open space. There was a reason DOOM/2 got it map design.
    - JohnBooty 3y ago

jezze 3y ago

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?

feiss 3y ago
I played Doom in my 486sx 25mhz..
- dspillett 3y ago
  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.
mrob 3y ago
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.
- phire 3y ago
  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.
  - dspillett 3y ago
    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.