OG Doom does not support (or need) hardware 3D acceleration. It’s not a polygonal rendering engine.
Relatedly, and probably not to anyone’s surprise, this is why it’s so easy to port to various oddball pieces of hardware. If you have a CPU with enough clocks and memory to run all the calculations, you can get Doom to work since it renders entirely in software. In its original incarnation – modern source ports have since worked around this – it is nonsensical to run Doom at high frame rates anyhow because it has a locked 35 FPS frame rate, tied to the 70hz video mode it ran in. Running it faster would make it… faster.
(Quake can run in software rendering mode as well with no GPU, but in the OG DOS version only in 320x200 and at that rate I think any modern PC could run it well north of 60 FPS with no GPU acceleration at all.)
OG Doom engine uses pre-built lookup tables for fixed point trigonometry. (table captures the full 360 degrees for sine and cosine with 10240 elements)
And CPUs still do it to this day. Nasty, nasty maths involved in figuring out an optimal combination between lookup table size and refinement calculations because that output can’t be approximate, it has to work how IEEE floats are supposed to work. Pure numerology.
Anyone who has ever had to maintain old code will tell you that this more civilized age is right now and that the past was a dark and terrible time.
Seriously, there were no standards, there was barely any documentation even in large organizations and people did things all the time that would get you fired on the spot today. Sure, you had the occasional wunderkind performing amazing feats on hardware that had no business of running these things, but this was not the norm.
I didn’t have to maintain it, actually I haven’t ever worked as a programmer. But I’ve patched a few FOSS things abandoned around 15-25 years before that to work as a hobby activity, some kind of digital archeology.
I think people also do things now for which they’d be fired on the spot 20 years ago. Everything changes.
I suspect what you call “no standards” means in fact “different standards”, but that’s just a cultural difference. Some project from 1995 may use “Hungarian notation” in variable names, well, that was normal then.
That adequate version control and documentation are, eh, a bit more of a norm now, - yes.
Also, this’ll blow your mind too, Doom wasn’t actually 3D. It was a clever trick involving the lack of the ability to look up and down. They used some sort of algorithm (I forget how it works exactly) to turn the 2D walls, doors, and platforms that appear from the top-down view in the map into vertical stacks of lines that “look” like 3D objects in front of you. The sprites are also all just 2D projections overlayed onto the game.
This system introduced all kinds of wierd quirks in the game, like the trippy effect you get when you activate no-clipping and clip through the edge of the map.
Like for instance, monsters and other sprite objects in the original incarnation of the Doom engine have infinite height. So you can’t step on top of, or over, any monsters if e.g. you are on a ledge high above them. That’s because they’re 2D objects, and their vertical position on the screen is largely only cosmetic. This is why you can’t run under a Cacodemon, for instance.
“Actors” (monsters, etc.) in Doom do have defined heights, but presumably for speed purposes the engine ignores this except for a small subset of checks, namely for projectile collision and checking whether a monster can enter a sector or if the ceiling height is too low, and for crush damage.
This was rectified in later versions of the Doom engine as well as most source ports. By the time Heretic came out (which is just chock-a-block full of flying enemies and also allows the player to fly with a powerup) monsters no longer had infinite height.
Most notably perspective only gets calculated on the horizontal axis, vertically there is no perspective projection. Playing the OG graphics with mouse gets trippy fast because of that. Doom doesn’t use much verticality to hide it. Duke Nukem level design uses it more and it’s noticeable but still tolerable. Modern level design with that kind of funk, forget it.
I learned recently that the Jedi Engine for the original Dark Forces had an additional trick. You could have a hallway over another hallway–which Doom cannot–but you can’t see both hallways at the same time. So there might be a bridge over a gorge, but the level design forces it so it’s a covered bridge, and you wouldn’t have an angle where you could see inside the bridge and down into the gorge.
Duke Nukem can do that, too, both it and Dark Forces use portal engines while Doom is a BSP engine. With a portal engine you’re not bound to a single global coordinate system, you can make things pass through each other.
Not actually a feature of the renderer you can do the same using modern rendering tech, though I can’t off the top of my head think of a game that uses it. Certainly none of the big game engines support it out of the box. You can still do it by changing levels and it wouldn’t be hard to do something half-way convincing in the Source engine (Half-Life, Portal, etc, the Valve thing), quick level loading by mere movement is one of its core features, but it isn’t quite as seamless as a true portal engine would be.
Doom64 accomplished this by adding a silent elevator sector type, so it could have bridges that appear to be floating “over” an underpass that you could walk through but you could also cross over the top. This, of course, immediately got turned into marketing bullshit trying very hard to imply that “Doom64 was fully truly 3D, and the Doom engine could now do room-over-room.”
Which it can’t. These weren’t bridges, they were cleverly disguised elevators.
What you eventually notice is that you can never look at one of these bridges from below and then from above, or vise-versa, without first passing through a tunnel or building that completely obscures your view of it. When your view is obstructed, you cross over a trigger somewhere that causes the elevator to, without making any sound (because elevator sounds were hard coded into original Doom), zip up to its cross-over-the-top position or its walk-under-the-bottom position. It could only ever be in one state at a time, never both.
Here’s a video that explains the limitations of the DOOM engine and with it also briefly how the rendering part of it works (from 4:08 onward) in a very accessible manner:
I remember those old games that would run faster to the point of hilarity if you put them on anything more modern than they were originally intended to run on. Like the game timing is tied to the frame rate.
This was by and large the reason for the “turbo” buttons on all those 286 and 386 computers back in the day. Disengaging the turbo would artificially slow down your processor to 8086 speed so that all your old games that were timed by processor clock speed and not screen refresh or timers would not be unplayably fast.
Quite a few more modern games have their physics tied to frame rate – if you manage to run them much faster than the hardware available at the time of their releases could, they freak out. The PC port of Dark Souls was a notorious example, as is Skyrim (at least the OG, non “Legendary Edition” or SE versions).
It’s embarrassing when a modern game does that. Game Programming 101 now tells you to keep physics and graphics loop timing separate. Engines like Unreal and Godot will do it for you out of the box. I’m pretty sure the SDL tutorials I read circa 2003 told you to do it. AAA developers still doing it on this side of 2008 should be dragged outside and shot for the good of the rest of us.
On launch, Spyro: Reignited Trilogy had a level you couldn’t complete unless you changed the settings to lock it to 30fps. It’s probably been patched by now, but was that ever infuriating.
There used to be dip switches on some older machines (386/486 era), eventually ‘turbo buttons’ that accomplished the same thing, toggling would cut the clock speed so older software would be compatible with clock speed. Those turbo buttons were more a ‘valet mode’ than anything, but it all died out before the Pentium/Athlon era to say the least
Command and Conquer Generals lets you choose game speed for skirmish matches, the natural cap of 60 and an option to uncap. You need superhuman reflexes to play with an uncapped speed on modern hardware !
OG Doom does not support (or need) hardware 3D acceleration. It’s not a polygonal rendering engine.
Relatedly, and probably not to anyone’s surprise, this is why it’s so easy to port to various oddball pieces of hardware. If you have a CPU with enough clocks and memory to run all the calculations, you can get Doom to work since it renders entirely in software. In its original incarnation – modern source ports have since worked around this – it is nonsensical to run Doom at high frame rates anyhow because it has a locked 35 FPS frame rate, tied to the 70hz video mode it ran in. Running it faster would make it… faster.
(Quake can run in software rendering mode as well with no GPU, but in the OG DOS version only in 320x200 and at that rate I think any modern PC could run it well north of 60 FPS with no GPU acceleration at all.)
OG Doom engine uses pre-built lookup tables for fixed point trigonometry. (table captures the full 360 degrees for sine and cosine with 10240 elements)
Tons of software did this for the longest time. Lookup tables have been a staple of home computing for as long as home computers have existed.
And CPUs still do it to this day. Nasty, nasty maths involved in figuring out an optimal combination between lookup table size and refinement calculations because that output can’t be approximate, it has to work how IEEE floats are supposed to work. Pure numerology.
I really like reading people talk about how better programmers in a more civilized age could do things.
Anyone who has ever had to maintain old code will tell you that this more civilized age is right now and that the past was a dark and terrible time.
Seriously, there were no standards, there was barely any documentation even in large organizations and people did things all the time that would get you fired on the spot today. Sure, you had the occasional wunderkind performing amazing feats on hardware that had no business of running these things, but this was not the norm.
I didn’t have to maintain it, actually I haven’t ever worked as a programmer. But I’ve patched a few FOSS things abandoned around 15-25 years before that to work as a hobby activity, some kind of digital archeology.
I think people also do things now for which they’d be fired on the spot 20 years ago. Everything changes.
I suspect what you call “no standards” means in fact “different standards”, but that’s just a cultural difference. Some project from 1995 may use “Hungarian notation” in variable names, well, that was normal then.
That adequate version control and documentation are, eh, a bit more of a norm now, - yes.
Interesting, learned something new from my silly comment!
Also, this’ll blow your mind too, Doom wasn’t actually 3D. It was a clever trick involving the lack of the ability to look up and down. They used some sort of algorithm (I forget how it works exactly) to turn the 2D walls, doors, and platforms that appear from the top-down view in the map into vertical stacks of lines that “look” like 3D objects in front of you. The sprites are also all just 2D projections overlayed onto the game.
This system introduced all kinds of wierd quirks in the game, like the trippy effect you get when you activate no-clipping and clip through the edge of the map.
Like for instance, monsters and other sprite objects in the original incarnation of the Doom engine have infinite height. So you can’t step on top of, or over, any monsters if e.g. you are on a ledge high above them. That’s because they’re 2D objects, and their vertical position on the screen is largely only cosmetic. This is why you can’t run under a Cacodemon, for instance.
“Actors” (monsters, etc.) in Doom do have defined heights, but presumably for speed purposes the engine ignores this except for a small subset of checks, namely for projectile collision and checking whether a monster can enter a sector or if the ceiling height is too low, and for crush damage.
This was rectified in later versions of the Doom engine as well as most source ports. By the time Heretic came out (which is just chock-a-block full of flying enemies and also allows the player to fly with a powerup) monsters no longer had infinite height.
Most notably perspective only gets calculated on the horizontal axis, vertically there is no perspective projection. Playing the OG graphics with mouse gets trippy fast because of that. Doom doesn’t use much verticality to hide it. Duke Nukem level design uses it more and it’s noticeable but still tolerable. Modern level design with that kind of funk, forget it.
I learned recently that the Jedi Engine for the original Dark Forces had an additional trick. You could have a hallway over another hallway–which Doom cannot–but you can’t see both hallways at the same time. So there might be a bridge over a gorge, but the level design forces it so it’s a covered bridge, and you wouldn’t have an angle where you could see inside the bridge and down into the gorge.
Duke Nukem can do that, too, both it and Dark Forces use portal engines while Doom is a BSP engine. With a portal engine you’re not bound to a single global coordinate system, you can make things pass through each other.
Not actually a feature of the renderer you can do the same using modern rendering tech, though I can’t off the top of my head think of a game that uses it. Certainly none of the big game engines support it out of the box. You can still do it by changing levels and it wouldn’t be hard to do something half-way convincing in the Source engine (Half-Life, Portal, etc, the Valve thing), quick level loading by mere movement is one of its core features, but it isn’t quite as seamless as a true portal engine would be.
Doom64 accomplished this by adding a silent elevator sector type, so it could have bridges that appear to be floating “over” an underpass that you could walk through but you could also cross over the top. This, of course, immediately got turned into marketing bullshit trying very hard to imply that “Doom64 was fully truly 3D, and the Doom engine could now do room-over-room.”
Which it can’t. These weren’t bridges, they were cleverly disguised elevators.
What you eventually notice is that you can never look at one of these bridges from below and then from above, or vise-versa, without first passing through a tunnel or building that completely obscures your view of it. When your view is obstructed, you cross over a trigger somewhere that causes the elevator to, without making any sound (because elevator sounds were hard coded into original Doom), zip up to its cross-over-the-top position or its walk-under-the-bottom position. It could only ever be in one state at a time, never both.
Here’s a video that explains the limitations of the DOOM engine and with it also briefly how the rendering part of it works (from 4:08 onward) in a very accessible manner:
https://youtu.be/ZYGJQqhMN1U
If you want a more in-depth explanation with a history lesson on top (still accessible, but much heavier), there’s this excellent video:
https://youtu.be/hYMZsMMlubg
Here is an alternative Piped link(s):
https://piped.video/ZYGJQqhMN1U
https://piped.video/hYMZsMMlubg
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Ooooo I absolutely want these—thank you!
I remember those old games that would run faster to the point of hilarity if you put them on anything more modern than they were originally intended to run on. Like the game timing is tied to the frame rate.
This was by and large the reason for the “turbo” buttons on all those 286 and 386 computers back in the day. Disengaging the turbo would artificially slow down your processor to 8086 speed so that all your old games that were timed by processor clock speed and not screen refresh or timers would not be unplayably fast.
Quite a few more modern games have their physics tied to frame rate – if you manage to run them much faster than the hardware available at the time of their releases could, they freak out. The PC port of Dark Souls was a notorious example, as is Skyrim (at least the OG, non “Legendary Edition” or SE versions).
It’s embarrassing when a modern game does that. Game Programming 101 now tells you to keep physics and graphics loop timing separate. Engines like Unreal and Godot will do it for you out of the box. I’m pretty sure the SDL tutorials I read circa 2003 told you to do it. AAA developers still doing it on this side of 2008 should be dragged outside and shot for the good of the rest of us.
Yeah its about time someone put down bethesda
I didn’t even know they still did it. I just remember games in the 80s and 90s doing that.
GTA SA 3 VC too
On launch, Spyro: Reignited Trilogy had a level you couldn’t complete unless you changed the settings to lock it to 30fps. It’s probably been patched by now, but was that ever infuriating.
Oh you mean fallout 4?
There used to be dip switches on some older machines (386/486 era), eventually ‘turbo buttons’ that accomplished the same thing, toggling would cut the clock speed so older software would be compatible with clock speed. Those turbo buttons were more a ‘valet mode’ than anything, but it all died out before the Pentium/Athlon era to say the least
Command and Conquer Generals lets you choose game speed for skirmish matches, the natural cap of 60 and an option to uncap. You need superhuman reflexes to play with an uncapped speed on modern hardware !