Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Doomkid

Game Theorists "Doom Wasn't 3D" video and my refutation

Recommended Posts

You know what? Thanks for doing this.

I actually cringe hard inside when I see the oft-repeated lie that Doom is essentially a 2D game. Sure, it's first-person Robotron in many aspects, but it is nonetheless 3D; stick a powerup in a 64x64x64 hole (because YES, sector heights are nonetheless modification of the Z axis) and run over it, you won't collect it - on top of the projectile Z axis evidence you presented and those sector heights (were it a 2D game, you could run right up a 512-high ledge because the height or Z axis is not a consieration) and we have a game that's 3D alright.

I think the confusion comes from the phenomenon of trying to descend a ledge with a monster or player beneath it, and stopping dead. That's a case of infinite height collision; something applied to solid actors and rocket explosions only. Ergo, the game is selectively 3D.

As for why, I'd guess that collisions between moving actors were difficult/CPU-intensive for 1993 hardware -- and I know rocket blasts would have been, because that's an extra dimension of calculation to deal with. Quake did it, but that demanded a "processor capable of floating-point math" in the readme file IIRC.

Doom. Is. 3D.

Just selectively so, no doubt by design.

Share this post


Link to post

I think you did a good job at correcting the glaring factual errors of the original video. I didn't note any comparably bad errors in your video, just some things that may have been confusing:

-Your points about looking up and down in 2.5D engines are off-topic in a video about the vanilla Doom engine, which doesn't have such a feature, and yet I've got an impression that you were implying that it does, maybe just due to my imperfect English skill, though. Anyway, mentioning looking up and down at all wasn't appropriate, IMO, or at least not while you were just explaining autoaim, and especially if it was in the same sentence as on-topic info about vanilla Doom.
-You've emphasized actors having a Z position, but floors and ceilings also have it, and that is critical for collision detection as well. For example, a lift descends to its lowest neighboring sector's floor level, or a crusher doesn't do any damage until its ceiling descends low-enough to touch the thing below it, or a step cannot be climbed if it's higher than a certain amount of map units, or a raised wall cannot be shot over unless the shot gets higher than the wall's top. You could have simply said that, in contrast with the essentially 2D rendering algorithm and even the 2D format in which maps are stored in files, Doom engine's collision detection is 3D - with several exceptions, such as collisions between actors that are both solid, explosion damage radius, and of course, being limited by no floors above each other.

Share this post


Link to post

Mathematically speaking, Doom maps are a geometrically restricted 3D -rather than being able to describe them in arbitrary terms of XYZ tuples, you're restricted to a pair of heights and ceilings per sector, so essentially you have a 2D floorplan "enriched" with floor and ceiling height information, and dimensional rigidity (e.g. you can't have tilted walls or floors, except with some extensions to the engine). In that sense they are more than pure 2D, and less than full, true 3D.

The gameplay code itself, esp. sprite movement and targeting, has some pure 3D elements, but they too are artificially limited/constrained in a lot of cases. E.g. the infinite monster height bug in retrospect sounds like laziness, as a proper Z-height hitbox check couldn't have been all than performance-hitting now, could it?

Share this post


Link to post
Maes said:

ss a proper Z-height hitbox check couldn't have been all than performance-hitting now, could it?



It's being done for projectiles, so obviously not. I think they just didn't manage to get it working right with the piss-poor movement code they wrote and simply disabled it so that it wouldn't bother them after the release. In fact, that's still a serious issue in all ports these days, the movement code is so fundamentally broken that there's no chance repairing it without turning it into something that's not Doom anymore.

Share this post


Link to post

Oh, it's this nonsense again.

Yeah, Doom is 3D. I'd point to his quote at ~6:50

The processor is hopping up and down a data tree and drawing sectors. You can apply different floor and ceiling heights to these sectors to create a variety of different room types without bogging down the processor. It's brilliant, it's sophisticated, but it's not actually 3D.


Here's the thing - it is. The Doom engine is still doing a perspective transform to map those walls, floors and ceilings onto your display (what "3D" at its heart really is), and the mathematics to do this is exactly the same as in a "true 3D" or modern game. Plus, the thing he says that I've quoted above is itself a non-sequitur. You know what else "jumps up and down a data tree" to do 3D rendering? The Quake engine, and nobody disputes that's 3D.

What the Doom engine does have is limitations, and nobody disputes this. These are the limitations that John Carmack was able to embrace and use as a foundation to build one of the first FPSes on the limited consumer hardware available in 1993. Specifically, Doom levels are all flat when viewed from above (you can't have a "room above a room") and you can't rotate the viewport - walls always appear vertical.

With these limitations as assumptions you can build an efficient 3D renderer that's based on drawing simple lines of texture in the vertical and horizontal planes (walls and floors/ceilings, respectively). Everything in the Doom engine is based around these assumptions, from the level formats to the texture formats. It's still a 3D renderer, but these assumptions allow simplification or exclusion of a significant amount of complicated math that a 486 just wasn't able to do fast enough.

Share this post


Link to post

look fraggle, i actually double checked all this and ran a conclusive test. i ran doom two at full screen on my Mac Book Pro and when looking at the screen i thought. Well. This looks 3d to me! However the story doesn't end their. for I then turned my Mac Book Pro ninety degrees to the left, and Lo And Behold it was flat all along

check and mate

Share this post


Link to post
fraggle said:

You know what else "jumps up and down a data tree" to do 3D rendering? The Quake engine, and nobody disputes that's 3D.


Well said. What is a binary space partition if not a data tree? This point's like arguing that static, pre-calculated lightmaps aren't really lighting (they are).

Share this post


Link to post

A game is considered 3D if it implements a model of a 3D space, in which things can move along all 3 axes, collisions between them are checked along all 3 axes, and the model can be rendered onto a (2D) screen to look "3D" in the same manner as the content of a movie frame or a photography of a 3D world looks "3D".

Share this post


Link to post

I understand how the third dimension works, but a representation of this on a screen or a picture... It's all just a representation.

Share this post


Link to post

Sure. The term "3D game" (or "true 3D") refers mainly to how the game works inside, not how it's represented on a screen.

Share this post


Link to post

Ive been hoping for a while now, since HD is becoming more and more popular, that screens would eventually start realistically simulating depth (the way you need to focus your eyes on things that are near or far away.) I'm nervous that my eyes are going to turn to shit with age the longer I spend many hours of my day looking at screens that are 12 inches away from my face.

Since it doesn't seem as soon as i once thought, I might need to look into doing eye exercises more often.

Share this post


Link to post

Thank you all for your responses, especially scifista and fraggle - I definitely should have clarified that the Z axis allows for things like moving sectors. Either way, I'm just glad I didn't get anything blatantly wrong! I also should have talked about monster's infinite height box as Jayextee mentioned, no idea how that slipped past me. That's what I get for essentially blabbing off the cuff. Thanks again, peoples :)

Share this post


Link to post

Nice explanation. I saw the Game Theory video a while ago and I was surprised back then, because I knew less stuff about the Doom Engine than I do now. Although it is a bit confusing explaining Doom's nature, I pretty much understand it now. And I have to say one thing. All hail John Carmack and the id staff for creating the masterpiece called Doom!!!

Share this post


Link to post
fraggle said:

Oh, it's this nonsense again.

Yeah, Doom is 3D. I'd point to his quote at ~6:50

Here's the thing - it is. The Doom engine is still doing a perspective transform to map those walls, floors and ceilings onto your display (what "3D" at its heart really is), and the mathematics to do this is exactly the same as in a "true 3D" or modern game. Plus, the thing he says that I've quoted above is itself a non-sequitur. You know what else "jumps up and down a data tree" to do 3D rendering? The Quake engine, and nobody disputes that's 3D.

What the Doom engine does have is limitations, and nobody disputes this. These are the limitations that John Carmack was able to embrace and use as a foundation to build one of the first FPSes on the limited consumer hardware available in 1993. Specifically, Doom levels are all flat when viewed from above (you can't have a "room above a room") and you can't rotate the viewport - walls always appear vertical.

With these limitations as assumptions you can build an efficient 3D renderer that's based on drawing simple lines of texture in the vertical and horizontal planes (walls and floors/ceilings, respectively). Everything in the Doom engine is based around these assumptions, from the level formats to the texture formats. It's still a 3D renderer, but these assumptions allow simplification or exclusion of a significant amount of complicated math that a 486 just wasn't able to do fast enough.



There are also some other elements that directly make the game 3D - my primary example I can think of is the potential loss of orientation. I can create a maze using a symmetrical flat for floors and ceilings, and block those lines from being shown in the automap. I start the player facing east. would the player know this without being told? in a 2-D grid-based game, like the many SNES RPGs out there, north is pretty obvious, even if the map rotates. Plus, you see more of the level from that perspective. even if you implemented a flashlight-like system where the only part of the level you see is what the player is facing, it's still easier to map out where you are due to your brain doing what it does best - reading and remembering diagrams, and locations on a grid, even while rotated. it's how we are able to play randomized matching tile games.

With 3D, your brain switches to a different style of thinking - landmarks. "oh, this turn has a vase" or "this room looks somewhat like a triangle". This is how humans keep track of their 3D world. If not landmarks with objects, it will be with left or right turns, or signs - anything will work. If there are not enough of these, you're lost. This is similar to being lost in a building (admit it, you've been there). All you need to disorient a person is to take the sun away, put him in a square building with four otherwise identical hallways, and tell him only doors on the east side will open. He'll try at most all four sides if he has to.

I cannot count how many times I've been lost in a Wolf3D level.

Share this post


Link to post

Also, the reason for room over room not possible is not the 2D map, but the 2D bsp tree. Build engine and Jedi engine also use 2D maps and they do support room over room. Both use portal rendering instead of bsp.

Share this post


Link to post
LogicDeLuxe said:

Also, the reason for room over room not possible is not the 2D map, but the 2D bsp tree.

The BSP tree, and also the BLOCKMAP. The former for rendering, spawning things and tracing hitscans, and the latter for general collision detection.

Share this post


Link to post
Jayextee said:

Putting paid to this horseshit via word of god. Or, 1 of the 2 Johns anyway.

I believe Carmack has actually addressed this a few times on his twitter already, heh

Share this post


Link to post
scifista42 said:

A game is considered 3D if it implements a model of a 3D space, in which things can move along all 3 axes, collisions between them are checked along all 3 axes, and the model can be rendered onto a (2D) screen to look "3D" in the same manner as the content of a movie frame or a photography of a 3D world looks "3D".

A good summary, except that I think it's a too restrictive definition. Half of the things you mention are actually 3D physics. I'd argue it's still 3D even if there are no physics in play; you can implement a complete 3D renderer without doing any collision detection for example.

LogicDeLuxe said:

Also, the reason for room over room not possible is not the 2D map, but the 2D bsp tree. Build engine and Jedi engine also use 2D maps and they do support room over room. Both use portal rendering instead of bsp.

scifista42 beat me to it, but yeah - it's not just the BSP tree. The 2D level assumption is baked into a bunch of data structures - both those on disk and internal to the engine.

Csonicgo said:

With 3D, your brain switches to a different style of thinking - landmarks. "oh, this turn has a vase" or "this room looks somewhat like a triangle". This is how humans keep track of their 3D world. If not landmarks with objects, it will be with left or right turns, or signs - anything will work. If there are not enough of these, you're lost. This is similar to being lost in a building (admit it, you've been there). All you need to disorient a person is to take the sun away, put him in a square building with four otherwise identical hallways, and tell him only doors on the east side will open. He'll try at most all four sides if he has to.

I cannot count how many times I've been lost in a Wolf3D level.

Totally agree about getting lost in Wolf3D levels - that's one aspect of the game that for me at least makes it very repetitive and not-fun to play for extended periods. I also agree that it's landmarks that we orientate ourselves with. But I don't agree that it's the lack of 3D that causes that problem; saying that implies that it's only the extra (z) axis that provides the ability to create landmarks.

It's worth referring back to the Doom FAQ's chapter, "What makes DOOM different from Wolfenstein 3-D?" and considering which of those features provide the ability to create landmarks. Certainly "Variable Height Floors and Ceilings" is one - for example a staircase might constitute a landmark that you couldn't have in Wolf3D. Or maybe it's "the room with the pit" or "the really tall room". But equally it could be "the triangle-shaped room" (Non-Orthogonal Walls), or "the room with the blinking lights (Light Diminishing/Light Sourcing). All of these are features you could just as easily add into a Wolfenstein-style engine - I once wrote a Wolf3D-style raycaster with Doom-style diminishing lighting, for example.

Share this post


Link to post
InsanityBringer said:

I believe Carmack has actually addressed this a few times on his twitter already, heh


Indeed. I just did a search and when asked his responses have differed; one's a variant on the oft-repeated "2D gameplay drawn in 3D" theory, another seems to align with my own "selectively-3D" idea.

I gather from some other responses it was not so much a technical reason as it was Carmack's inexperience at the time, that things were done as they were. Shatters the mystique a little, in a pleasant way; but is nothing definitive.

Share this post


Link to post

Good video and fraggle already addresses my only complaint and that's the idea that renderer itself isn't 3D, since it in fact is. When projecting linedefs to the screen, you need the X and Y, calculated from angle and height, AND you need a Z - in this case, the depth of the object inside the projection. That's three dimensions from the camera's perspective already, neglecting the fact that the world space is also 3D, with x,y,z coordinates (plane heights require the worldspace "z" which is equivalent to the sector heights). Sprites also require the worldspace z, and must similarly transform it through the perspective projection, to determine where the sprite should start and stop on screen.

As fraggle said, this ultimately is no different than what any other 3D renderer does, and it's only the limitations of the data structures involved that let the process be achieved faster and simpler than a general 3D polygon renderer. Doom is really a pair of special-case 3D plane projectors which can only handle planes that are either orthogonal to the X or Y axes in screenspace. That's the best way to put it in mathematical terms. Not "2.5D," which I will generally let pass since it sort of describes the fact there are limitations in the renderer, and especially not "2D".

Share this post


Link to post

The original video is very confused.

The first flaw in his reasoning is that he completely confuses rendering with simulation. When he basically says that it's a top-down map because the computers didn't have enough power for a third axis -- no, no, no! This is plain old confusion.

I understand it's not an intuitive notion, but the simulation and the rendering are different notions. You can do a 3D rendering of a 2D simulation (and that's what raycasting does -- Wolfenstein 3D has a 2D grid world, which is rendered in a 3D perspective); and you can also do a 2D rendering of a 3D simulation. The simulation is just the computer crunching numbers about stuff that happens; the rendering is the representation to the player.

The second flaw is that he didn't delve into the code. When he says that shooting monsters above you isn't a design choice, he betrays that he never bothered to check his assumptions.

    slope = P_AimLineAttack (actor, angle, MISSILERANGE);
Gee, why are there things like that in the code? What does slope mean?


Now it's true that the Z axis is the runt of the litter in Doom. It's not treated by the engine in the same way that the horizontal dimensions are. The X and Y movements and the Z movements are treated separately in discrete steps instead of all at once, and over-or-under collisions are deeply flawed because of that. But none of these things are relevant for rendering, and none of these things were required to get Doom to run on 90s PCs.

Share this post


Link to post

@Quasar: Well, the BSP tree partitions the map in 2D only, therefore traversing the tree orders map geometry near-to-far from the camera in 2D only. Also, checking whether some geometry is completely out of view, or whether an already rendered geometry obstructs an entire part of the view, so that there's no point in traversing areas behind said geometry, is done in 2D (possibly using some not-entirely-2D-only tricks, which definitely aren't entirely 3D either, though). That's the 2D part of it. The transformations that make the traversed geometry appear on screen are already 3D (even though they heavily rely on the limited structure of the geometry).

Share this post


Link to post

I'm pretty sure one of the main reasons why collision between solid actors is 2D is due to the fact that mob-on( top of )-mob logic is pretty much a big ol' can of worms in any game. Even in 2D, cartoonish games like Mario and Sonic don't like to deal with it, and usually just let the mobs phase right through each other or deal collision / jump damage, if it's mob-on-player. When you consider that the Z-axis is what's responsible for allowing mobs to move in Doom ( the player has 0 air control in vanilla, and non-flying monsters won't move if they don't have something below their feet ) and the fact that such collisions are kinda goofy in source ports that add them, it's not hard to see the decision as simply a matter of not being assed to work out what should happen when an actor is standing on top of another.

Melee not respecting height is likely for the same reason - rather than having to consider whether or not monsters would have to get closer to melee someone above or below them ( since they'd be angling the imaginary hitscan up or down, meaning it'd cover less XY distance ), or if they'd just use some sort of additional Z distance check in addition to their standard one and what constraints it should use, they just figured it'd be uncommon enough to not care about and went the lazy way.

Share this post


Link to post
Arctangent said:

I'm pretty sure one of the main reasons why collision between solid actors is 2D is due to the fact that mob-on( top of )-mob logic is pretty much a big ol' can of worms in any game.

Nah.

It just requires more complicated maths, that's all. But there are plenty of games that have no problems with full 3D collisions; including some vintage games: take Descent, for example.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×