3 ms·

I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system. 320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second.

I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system. 320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic. I know it's not a true 3D engine, and the status bar took up a good amount of space, but even accounting for that, you still don't get a lot of clock cycles.

joombaga 5y ago
What makes Doom's 3d engine not "true"?
- monocasa 5y ago
  The engine is limited such that it fundamentally can't do up/down rotation of the camera.
- bonzini 5y ago
  It can only draw horizontal floors and vertical walls (so the map is essentially 2D even though it is drawn in 3D). The player also cannot tilt their head sideways.
- jsolson 5y ago
  As others noted, it only supported horizontal walls and floors. More specifically, though, it only supported _one_ gap (e.g., a single window or door). You couldn't stack floors on top of each other. This allowed a single ray cast against the 2D map to learn which vertical slices of wall texture to paint (no pitch or roll, remember). Floors and ceilings could be painted in vertical order (above / below the horizon line - "floor" and "ceiling" being explicit for any given open area), iirc, and walls filled in based on the ray cast from the eye.
Narishma 5y ago
> I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system. It didn't. It ran at ~25 FPS on a 66 Mhz 486 and only ~15 FPS on a 33 Mhz system. It needed a Pentium to reach half the refresh rate, which was 35 FPS at the time. https://youtu.be/HNlcZetLzY8?t=209 https://youtu.be/HNlcZetLzY8?t=209
- Sohcahtoa82 5y ago
  That's still only ~41 clocks per pixel. I wonder how many clocks multiple and add instructions took on a 486.
  - bonzini 5y ago
    You don't need to multiply in the inner loop if you draw along a constant-z line (which is easy to do if the walls are all horizontal or vertical).
dehrmann 5y ago
- Textures were just skewed images - Everything that wasn't a room was a 2d sprite - Very limited lighting effects - An effectively 2d environment It's still impressive. It's just that 3d games weren't "ready" until the Quake II/Unreal/PS2 era.
tenebrisalietum 5y ago
> 320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic. GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.
- xgkickt 5y ago
  >GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. Two pixels per cycle for flat shaded or rectangular primitives. Add another cycle for color interpolation, and another for on-cache texture reads (divided by how many texels are packed into 16 bits). The GPU is clocked around 53MHz so the range of 'many' here is roughly 1 to 4, ignorning that a CPU renderer would probably write two pixels at once. The CPU is also hampered by main memory reads taking a minimum of 5 cycles. Pipelining helps a little but extensive scratchpad use, such as putting the stack on it, was essential. DOOM PSX did use triangles for the walls, just that they were a single pixel wide.
- Sohcahtoa82 5y ago
  > GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. GPUs do it via massive parallelization. > DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays. In the days of DOOM, did the video card even offer any sort of acceleration? I was under the impression that all the texture scaling was done on the CPU. So while it rendered walls as vertical strips, it would still have to interpolate across the strip on the CPU.
  - 5y ago
pengaru 5y ago
What always impressed me about Doom was the dynamic shading/lighting effects they managed in a 256-color mode. The "3D" part wasn't any more impressive than Wolfenstein3D was, which was running on significantly slower PCs. I dabbled in PC demo programming at the time, the limited color palette was a major challenge for me in attempting shaded texture mapping. Once we had ubiquitous "TrueColor"/"DirectColor" RGB modes, the shading challenges became trivial. Doom made clever use of a finite colorspace. When I tried recreating some of that myself it became rather obvious why Doom's palette was so muted and basically dark gray/brown/green gradients they could then illuminate. But it worked very well for Doom.
rasz 5y ago
- it didnt, at least not Intel x86 MHz - doom doesnt operate on pixels, it operates on constant-z planes (lines), you can scale linearly inside those (cheap 2D operation). How Carmack did it? He cheated by deciding to never look down/up or draw slopes :) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' https://www.youtube.com/watch?v=xn76r0JxqNM https://www.youtube.com/watch?v=xn76r0JxqNM Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math

joombaga 5y ago

What makes Doom's 3d engine not "true"?

monocasa 5y ago
The engine is limited such that it fundamentally can't do up/down rotation of the camera.
bonzini 5y ago
It can only draw horizontal floors and vertical walls (so the map is essentially 2D even though it is drawn in 3D). The player also cannot tilt their head sideways.
jsolson 5y ago
As others noted, it only supported horizontal walls and floors. More specifically, though, it only supported _one_ gap (e.g., a single window or door). You couldn't stack floors on top of each other. This allowed a single ray cast against the 2D map to learn which vertical slices of wall texture to paint (no pitch or roll, remember). Floors and ceilings could be painted in vertical order (above / below the horizon line - "floor" and "ceiling" being explicit for any given open area), iirc, and walls filled in based on the ray cast from the eye.

Narishma 5y ago

> I always wonder about how the hell DOOM ran at 30 fps on a 33 Mhz system. It didn't. It ran at ~25 FPS on a 66 Mhz 486 and only ~15 FPS on a 33 Mhz system. It needed a Pentium to reach half the refresh rate, which was 35 FPS at the time. https://youtu.be/HNlcZetLzY8?t=209 https://youtu.be/HNlcZetLzY8?t=209

Sohcahtoa82 5y ago
That's still only ~41 clocks per pixel. I wonder how many clocks multiple and add instructions took on a 486.
- bonzini 5y ago
  You don't need to multiply in the inner loop if you draw along a constant-z line (which is easy to do if the walls are all horizontal or vertical).

dehrmann 5y ago

- Textures were just skewed images - Everything that wasn't a room was a 2d sprite - Very limited lighting effects - An effectively 2d environment It's still impressive. It's just that 3d games weren't "ready" until the Quake II/Unreal/PS2 era.

tenebrisalietum 5y ago

> 320 * 200 pixels @ 30 fps means they needed to calculate 1,920,000 pixels per second. With a 33 Mhz CPU, that's ~17 clock cycles per pixel, and that doesn't account for time to handle game logic. GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays.

xgkickt 5y ago
>GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. Two pixels per cycle for flat shaded or rectangular primitives. Add another cycle for color interpolation, and another for on-cache texture reads (divided by how many texels are packed into 16 bits). The GPU is clocked around 53MHz so the range of 'many' here is roughly 1 to 4, ignorning that a CPU renderer would probably write two pixels at once. The CPU is also hampered by main memory reads taking a minimum of 5 cycles. Pipelining helps a little but extensive scratchpad use, such as putting the stack on it, was essential. DOOM PSX did use triangles for the walls, just that they were a single pixel wide.
Sohcahtoa82 5y ago
> GPUs, even the primitive PSX one, will draw many in a single CPU cycle. I can't find information on the PSX GPU fill rate but I'm sure it's faster than 1 pixel per CPU cycle. GPUs do it via massive parallelization. > DOOM didn't use the GPU to draw the walls/floors as triangles but did use the GPU to draw the scene as vertical strips. DOOM also relied on the 1Kbyte "scratchpad RAM" which was the CPU cache mapped into the address space and not subject to DMA delays. In the days of DOOM, did the video card even offer any sort of acceleration? I was under the impression that all the texture scaling was done on the CPU. So while it rendered walls as vertical strips, it would still have to interpolate across the strip on the CPU.
- 5y ago

pengaru 5y ago

What always impressed me about Doom was the dynamic shading/lighting effects they managed in a 256-color mode. The "3D" part wasn't any more impressive than Wolfenstein3D was, which was running on significantly slower PCs. I dabbled in PC demo programming at the time, the limited color palette was a major challenge for me in attempting shaded texture mapping. Once we had ubiquitous "TrueColor"/"DirectColor" RGB modes, the shading challenges became trivial. Doom made clever use of a finite colorspace. When I tried recreating some of that myself it became rather obvious why Doom's palette was so muted and basically dark gray/brown/green gradients they could then illuminate. But it worked very well for Doom.

rasz 5y ago

- it didnt, at least not Intel x86 MHz - doom doesnt operate on pixels, it operates on constant-z planes (lines), you can scale linearly inside those (cheap 2D operation). How Carmack did it? He cheated by deciding to never look down/up or draw slopes :) 'HandmadeCon 2016 - History of Software Texture Mapping in Games' https://www.youtube.com/watch?v=xn76r0JxqNM https://www.youtube.com/watch?v=xn76r0JxqNM Chris Hecker (Microsoft/Maxis/etc): that's a classic Carmack thing which is like Fuck those general problems, Im gonna solve this other problem perfectly John Miles (ORIGIN/Miles Design/etc): Its all about not doing the math, we were still at a point in time when you won by not doing the math