why can't the original doom room over room?

[txeptsyip]

So full disclosure this is for a second-year undergraduate university project

 

I am looking for clarification on why some of the limitations of doom existed (and also Wolfenstein 3D and build engine games but the focus is on doom) and if anyone can point me in the direction of potentially useful information that would be helpful

 

My main issue is this: why does the original doom engine not support room over room? I have found talk about how source ports like ZDoom and RORDoom achieve room over room (Zdoom appears to use portals(?) or linking dummy sectors to "floor over floor" sectors(?) - not 100% sure on this. and RORDoom lets two sectors overlap each other but this approach is apparently "not in general use anymore")

 

most limitations I have found appear to be mostly conscious choices in the name of optimization, for example the Z-Clipping issue appears to be the engine resolving collisions as Two dimensional due to the Z dimension not really existing much in the game to the extent that it can easily be ignored and with the added fact that 2D collision detection and resolution is overall much "cheaper" than 3D collision detection and resolution it is my guess that the 2D only collisions are in the name of optimization

 

but why isn't there any room over room? the ways source ports achieve room over room mostly hurts my head and sound like hacky workarounds but I don't think the original developers sound like people who have been above using hacky workarounds so long as they work

 

also, is this write up i found accurate? https://twobithistory.org/2019/11/06/doom-bsp.html

[dasho]

Shouldn't you be determining why it can't if it's your project? 

[D4NUK1]

My idea would be comparate the original source code of how the Doom renders the visuals versus how other source port do it or fix it?
https://doomwiki.org/wiki/Doom_rendering_engine

 

[Eon Toad]

This is just my amateur understanding, so someone feel free to correct me.

 

I'm simplifying here, but the way the Doom engine creates a 3D space on your screen is by taking a 2D map that's broken up into sectors with floor and ceiling height values then calculating the distance and height of walls and objects in your field of view to show a 3D image. That means each sector can only have one floor and one ceiling.

 

If you've ever used a Doom editor to make a level, it looks more like you're building a top-down isometric game. The z axis only exists as a set of stored values that your computer uses to do trigonometry. Hence the constant debates over whether Doom is really 3D.

 

Or are you asking what specific technical limitations of the time required them to do it the way in the first place? That's beyond my understanding.

[Gez]

1 hour ago, txeptsyip said:

I am looking for clarification on why some of the limitations of doom existed (and also Wolfenstein 3D and build engine games but the focus is on doom) and if anyone can point me in the direction of potentially useful information that would be helpful

I really really really recommend Fabien Sanglard's books on Wolfenstein 3D and Doom. And if it's for a university project, the expense to get them in paper version is fully justified.

 

But even if you don't get the books, you should at least read the code reviews:

https://fabiensanglard.net/wolf3d/index.php

https://fabiensanglard.net/doomIphone/doomClassicRenderer.php

https://fabiensanglard.net/duke3d/index.php

https://fabiensanglard.net/quakeSource/index.php

https://fabiensanglard.net/quake2/index.php

https://fabiensanglard.net/quake3/index.php

https://fabiensanglard.net/doom3/index.php

 

1 hour ago, txeptsyip said:

but why isn't there any room over room? the ways source ports achieve room over room mostly hurts my head and sound like hacky workarounds but I don't think the original developers sound like people who have been above using hacky workarounds so long as they work 

Long story short, because of the BSP. Every single point in the game world is part of a sector; even those that are "outside" of map geometry. Best way to demonstrate it is to use the noclip cheat to explore the void, and you'll notice that you'll walk on sectors that are "projected" beyond their walls. Your altitude will suddenly change as you cross an invisible sector boundary, you may take damage as you wander into a damaging sector, etc. even though you're out of bounds.

 

Because of that, every single [X, Y] point belongs to a sector. A single sector. Room-over-room requires your [X, Y] point to belong to sector A at a given altitude and to sector B at another (and potentially at sectors C, D, E, etc. too at others). There's no good way of making a "sector over sector" in the Doom engine; it's what RORDoom did but it required hacky workarounds to get the same 2D space to belong to two (or more) different nodes of the BSP tree.

 

Other methods to get ROR in Doom, that are still used, are the 3D floor (basically, a polygon of map geometry that is floating at an arbitrary height), which has the advantage of allowing a single sector to have two (or more) different floors; and the portal that allows to connect a sector with another sector, so that one will be the upper and the other will be the lower, and they get "stitched up" together during the game while being at different places. So with a 3D floor system, your two (or more) floors are in the same sector and the same node of the BSP tree; whereas with portals they are in geographically separate areas of the map and are separate sectors in separate nodes.

 

Duke 3D, with its portal-based renderer, natively supports the latter method. Quake and other more modern engines have done away with the concept of sectors altogether, replacing it with the concept of brushes and meshes.

 

1 hour ago, txeptsyip said:

also, is this write up i found accurate? https://twobithistory.org/2019/11/06/doom-bsp.html 

Yes.

[lubba127]

The people in this thread have done a better job at explaining ROR than I ever could, but I also want to connect how Doom is still running actors in 3D space despite using 2D map setups.

 

Long story short, my understanding of it is that while Doom level geometry is rendered and built in a 2D space, all of the actors are operating in a 3D space, because they all take a z axis into consideration when functioning. Most shortcomings used to debunk Doom as a 3D game (lack of freelook, infinite monster height, auto aim) are results of shortcomings in how computers render and store assets in memory back when the game released. 

 

So the rooms are 2D but look 3D, and the entities are 3D but look 2D. crazy stuff.

[Gez]

17 minutes ago, lubba127 said:

Most shortcomings used to debunk Doom as a 3D game (lack of freelook, infinite monster height, auto aim) are results of shortcomings in how computers render and store assets in memory back when the game released. 

I'd rather say they are the consequences of optimization strategies chosen by Carmack and his team. It's not the memory footprint that prevented Doom from having a true generic polygon renderer, it's the processing cost of arbitrary polygon rendering that did. But by constraining the engine to only have to deal with polygon sides that are either fully vertical (walls) or fully horizontals (floors and ceilings), they could create a special-case polygon renderer with a lot of optimizations that got acceptable performances on a x486 computer.

[ebrl]

11 minutes ago, Gez said:

I'd rather say they are the consequences of optimization strategies chosen by Carmack and his team. It's not the memory footprint that prevented Doom from having a true generic polygon renderer, it's the processing cost of arbitrary polygon rendering that did. But by constraining the engine to only have to deal with polygon sides that are either fully vertical (walls) or fully horizontals (floors and ceilings), they could create a special-case polygon renderer with a lot of optimizations that got acceptable performances on a x486 computer.

...and god forbid you only had a 386:

[Biz!]

So it could run on a 386.

 

 

[Uncle 80]

4 minutes ago, Biz! said:

So it could run on a 386.

 

 

Yup. I installed Doom at my dad's home computer, which was a little outdated at the time - it was a 386 16mhz (albeit upgraded to 8mb ram). On a small level, one could enjoy about 10-15 fps with the detail set to low, and the window shrunk to about half size.

[DNSKILL5]

Since you mentioned Wolfenstein 3D and Duke 3D, and everyone else has mentioned Doom. I’ll try to give you some additional info from what Gez shared on those games. 

Wolf 3D was designed to be very simple and easy to run on even the weakest of computers. Some might say they played it too safe, but it did become a huge hit for Id and part of that is likely due to how accessible it was. The limitations of this game are mostly that maps are 64x64 grids, with each square representing a 64x64 space. Each sprite and wall (doors are also a type of wall) take up a 64x64 square when added to the map grid. You are limited on how many objects (sprites, including decorations and guards) that can be placed in the map, as well as how many doors. The floor and ceiling colors can be changed for each level, but they are always solid colors. These limitations are mostly for performance reasons. They wanted Wolfenstein 3D to be fast, really, really fast. They initially had a much bigger vision for this game. Stealth elements were implemented as well as a 5th weapon, but they were all removed before the shareware was completed. Some of the code is still in the game, though, but nonfunctional. The ShadowCaster engine was apparently created during Wolf 3D’s development and while it had more features for making maps less flat, it was not what they were wanting for a game they wanted to be fast and easy to run on weaker hardware. So, ROR just wasn’t something they were likely considering at the time.

 

Duke 3D uses trickery to create ROR. Usually it is done by secretly teleporting the player from one place to the other seamlessly. One example is in the very first level when you drop down the ventilation shaft. You can sort of notice it in game when this happens (and even break the sequence to where you get stuck at the bottom of the vent), but the best way to see is to look at the maps through the BUILD editor. You will see that the shaft only goes down so far, and the outside street area is a completely different sector. This is also the case for underwater areas. The underwater areas are separate sectors that you can teleport in and out of. So, while the game gives off the allusion that there are rooms stacked on top of each other, it is not strictly room over room. Other BUILD games did the same thing but could render the rooms to look like they’re on top of each other (Shadow Warrior), but it was still mostly a really good illusion. TROR is a feature that EDuke32 implemented that does allow for true room over room, but this was not in the original DOS games. 

[Gez]

38 minutes ago, Biz! said:

So it could run on a 386.

Yeah, I played the shareware version on a 386DX40 -- I think we had it overclocked, though. I didn't need to make the view window as small as pictured, but I did have to shrink it a bit nonetheless. Full screen or even just the statusbar was asking for trouble.

[Redneckerz]

9 minutes ago, Gez said:

Yeah, I played the shareware version on a 386DX40 -- I think we had it overclocked, though. I didn't need to make the view window as small as pictured, but I did have to shrink it a bit nonetheless. Full screen or even just the statusbar was asking for trouble.

One could wonder how it would have performed if FastDoom was around back in the day.

 

The fact it could run on it was a good example of versatility. The first Igel terminal, the ETherminal, could run Doom (386DX40). Obviously nobody tried to run Doom on such a tiny machine back in the day, but it could.

[Dubbag]

because it's not a 3D game.

[dasho]

11 minutes ago, Dubbag said:

because it's not a 3D game.

[CittyKat112]

12 minutes ago, Dubbag said:

because it's not a 3D game.

It is, the infinite height limitation was removed in Heretic and it uses the same engine.

[Edward850]

17 minutes ago, Dubbag said:

because it's not a 3D game.

1 minute ago, CittyKat112 said:

It is, the infinite height limitation was removed in Heretic and it uses the same engine.

Wrong way to describe it, as nothing in Doom has infinite height (well except for explosions).

[CittyKat112]

3 minutes ago, Edward850 said:

Wrong way to describe it, as nothing in Doom has infinite height (well except for explosions).

Monsters + some decorations do.

[Klear]

1 hour ago, CAM-7EA said:

Duke 3D uses trickery to create ROR. Usually it is done by secretly teleporting the player from one place to the other seamlessly.

 

You could also draw sectors over each other (potentially leading to non-euclidean geometry like in levels Lunatic Fringe and Tier Drops) or create walkable bridges out of flat sprites (first level has one of those just before the exit.

[DNSKILL5]

Just now, Klear said:

 

You could also draw sectors over each other (potentially leading to non-euclidean geometry like in levels Lunatic Fringe and Tier Drops) or create walkable bridges out of flat sprites (first level has one of those just before the exit.

Yep. that is true. The sprite bridges don't let you cross usually if you're crouching before walking onto it, at least in the first level I've experienced that. So even it has some limitations in its use for those features as well.

[Edward850]

10 minutes ago, CittyKat112 said:

Monsters + some decorations do.

No. All monsters and things have a height defined, they must logically given A) there is only a single template for all mobjs and B) you can fire over/under monsters. Projectiles and hitscans can pass right over them. Monsters are also obviously blocked by short sectors and are affected by crushers at different heights. These are all things you can observe.

[Shepardus]

8 minutes ago, CittyKat112 said:

Monsters + some decorations do.

They have heights, that's how projectiles are able to pass over/under them and why monsters can't walk into places where the ceiling is too low. The height is just ignored for certain checks.

[CittyKat112]

Just now, Edward850 said:

No. All monsters and things have a height defined, they must logically given A) there is only a single template for all mobjs and B) you can fire over/under monsters.

Ah, sorry then. I got this information from Doomwiki and didn't do a proper search. I knew projectiles can fly over/under things though.

[Klear]

Hot take: Doom is not really 3D and neither is Quake or Half-Life or Doom Eternal. It's all just some fuckery to trick our brains to think it's 3D, it's just gradually more advanced kinds of fuckery and the difference between a 3D and non-3D engine is largely arbitrary - meaningless.

 

Furthermore, Doom is definitely not a pipe.

 

 

[txeptsyip]

4 hours ago, dasho said:

Shouldn't you be determining why it can't if it's your project? 

Its a two week group presentation project where we chose a game or series to compare different aspects thereof to other games and then do a presentation

 

for my part in the presentation, I decided to look at the first doom and compare its limitations that we don't see today to other early well known first person shooters (the logical choices here being Wolfenstein and duke3D)

 

turns out that was a much bigger rabbit hole than I anticipated, probably should have explained more about the project and what angle it comes from

[magicsofa]

 

1 hour ago, lubba127 said:

So the rooms are 2D but look 3D, and the entities are 3D but look 2D. crazy stuff.

 

Sectors have two Z values associated with them. The rooms are 3D, and look 3D unless you are looking through a 2D map view. Which brings me to this:

 

2 hours ago, Eon Toad said:

If you've ever used a Doom editor to make a level, it looks more like you're building a top-down isometric game. The z axis only exists as a set of stored values...

 

I think there's a bit of a disconnect, or more accurately a "false connection" for many people, between the game's data vs what is shown on the screen. Which is totally understandable, but ironically you contradicted yourself in just the right way.

 

The game data is stored sort of like this:

Quote

 

Vertex 1: 0,0

Vertex 2: 64,0

Vertex 3: 64,64

Vertex 4: 0,64

 

Line 1: Connects Vertex 1 and 2

Line 2: Connects Vertex 2 and 3

(etc)

 

Sector 1: Made of Line 1, 2, 3 and 4, with floor at 0 and ceiling at 128

 

 

So how many dimensions is that? I'd say none: it is just a list of numbers and references. The vertexes have two numbers associated with them for X and Y position, and the sectors have two numbers for Z positions... but that doesn't just have meaning by itself. The renderer reads those values and paints the screen accordingly, the same way you could interpret them and draw a cube of the appropriate size. The data for the map geometry contains information intended for X, Y, and Z positions. But the interpretation is where that is put into practice.

 

You could store things differently.. for example, the vertices could have X, Y, and Z values instead. Once you do that, the interpreter also has to change. Now you have to deal with the possibility of a sloped surface. The Doom engine uses shortcuts in the interpretation phase, knowing that the data is stored in a specific way, in order to make the calculations (and thus time to final draw) faster.

 

Early map editors just showed a top-down view because that was enough to make a map, but as soon as there was a 3D view (and one with realtime editing, wow!) nobody looked back. Still, you need the top-down view to be able to draw lines and place objects easily. That doesn't mean the map is 2D... it means that it's convenient for you to be able to only focus on the X/Y plane when doing some tasks. "Full 3D" editors also use top-down view, they just need a side-view as well. You could have a side-view in Doom mapping but it wouldn't really help you with anything that you couldn't do in perspective view.

 

[Dubbag]

lol I don't know, whatever.

[txeptsyip]

6 hours ago, Edward850 said:

No. All monsters and things have a height defined, they must logically given A) there is only a single template for all mobjs and B) you can fire over/under monsters. Projectiles and hitscans can pass right over them. Monsters are also obviously blocked by short sectors and are affected by crushers at different heights. These are all things you can observe.

so from that it would appear not all collisions are resolved as 2D only select interactions (such as the wikis example of a player at a 640 block height being blocked (and even attacked(?) by a monster at 0) are resolved as such? (oh it even says that "Doom features a limited z-clipping that is only designed for projectiles and hitscan attacks")

 

that sounds like the sort of thing you would see when you are trying to squeak out all the performance you can at what point in the game is the player expected to jump over a monster

Edited April 22, 2023 by txeptsyip

[DrinkyBird]

I'm just impressed that in 2023, when Doom is almost thirty years old, "is Doom 3D" and "do monsters have infinite height" are still hot topics.

Edited April 20, 2023 by DrinkyBird

[Edward850]

1 hour ago, txeptsyip said:

so from that it would appear not all collisions are resolved as 2D only select interactions (such as the wikis example of a player at a 640 block height being blocked (and even attacked(?) by a monster at 0) are resolved as such? (oh it even says that "Doom features a limited z-clipping that is only designed for projectiles and hitscan attacks")

Basically the only thing that doesn't check height is collisions between two solid actors, the routine is actually skipped (specifically it checks if the object is a missile, and other objects just aren't solid and thus ignored for clip rejection). This is because Doom lacks the ability to have knock-on collisions from sector height movement, and actor standing on another actor would get stuck inside eachother if the floor moved up underneath because there's no way to transfer that information across. Hexen and heretic seemingly fixed this, Strife removed the restriction but didn't fix it.

Edited April 20, 2023 by Edward850