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

Really fascinating that the Sega Saturn could only do quads rather than triangles. Is there a particular reason this served as an advantage at the time?

Share this post


Link to post

The only real advantage I can think of for quads is that they're vastly easier to subdivide and extrude from and the like which is why Blender uses them by default. Other than that and maybe cube shaped things demanding fewer polygons, I can't really think of anything else.

Share this post


Link to post

Quads are common in many basic 3D structures, it's faster to render one quad than 2 triangles, and hardware can be made both cheaper and faster by supporting less features than more (in this case, by supporting quads-only than supporting both quads and triangles).

Share this post


Link to post
GoatLord said:

Really fascinating that the Sega Saturn could only do quads rather than triangles. Is there a particular reason this served as an advantage at the time?


Probably the fact that the Saturn's "quad rendering" was more like an overblown 2D hardware accelerator forced to act as if it was a fully 3D one, while in fact it was not -that also explained its inability to perform affine rendering, among other things.

Share this post


Link to post

Weren't the Saturn and Ps1 both stricken with affine rendering? That's why Carmack, to his own detriment, demanded the Saturn version of Doom be software rendered. The only console that had 3D correction at the time was the N64.

Share this post


Link to post

I meant unable to perform perspective-correct texture mapping, my bad. But that simply meant that everything just looked like crap and "dirty" on those early 3D consoles. On top of that, the Saturn just dug its own grave by not really helping a truly 3D approach when rendering and ever during game design. It was all a FORCED and PAINFUL attempt at looking 3D.

Share this post


Link to post

In their defense, inability to perform perspective-correct texture mapping also plagued the Ps1, the Ps1 simply had better capacity to perform 3D compared to the Saturn. Apparently, Nintendo pointed to the Saturn as justification for holding off on the N64's release, wanting to get the hardware right.

Share this post


Link to post

It's not the quads per-se, it's the way they are used by the Saturn hardware. Essentially it's a 2D accelerator working overtime, drawing rotated and distorted/scaled tiles/sprites as if they were 3D rendering primitives. So there's no hardware support for e.g. full-scene geometry transform, lighting, depth clipping etc.

It comes quite close to being a 3D accelerator, but it's not. Kinda like the bumblebee that shouldn't be able to fly, only that nobody told it so ;-)

Share this post


Link to post

I was thinking about Doom's pusedo-3D nature last night and it occurred to me that the X/Y grid that is the basis of each map's geometry is a single 2D plane, which is why overlap is impossible. If there were overlap, then the Z axis would be fully functional, rather than just acting as a heightmap for X and Y.

Share this post


Link to post

In addition, it's like having TWO independent height maps which however are constrained to share the same 2D partitioning (sectors) when interpreting them. Doom maps are not even full XY grids either, with information at every possible XY coordinate, but more like vector maps, defining broad, closed, non-overlapping areas (sectors) with just a few vectors.

Share this post


Link to post
GoatLord said:

the X/Y grid that is the basis of each map's geometry is a single 2D plane, which is why overlap is impossible.

Not really. The format of the map geometry itself (both as saved in a wad and as being processed in the engine's memory) technically allows overlapping, and is able to describe any possible and even impossible 3D structure (except slopes and portals between places with different coordinates), because nothing prevents different vertices, linedefs and sectors to share the same positions, and the sector references on sidedefs (defining which sector neighbors with which one) are basically arbitrary. The real reason why such structures are impossible in the game is that BSP nodes, blockmap, and the related rendering and collision-detecting parts of the engine, can't handle such geometry.

Share this post


Link to post

That's neither an exploit or a hack - it's simply a statement that the map format allows doesn't prevent you from overlapping vertices, linedefs, and sectors, just that the nodebuilder and game itself doesn't know what to do in that case.

Technically, I think you could make the same vertices for five different sectors, though that won't actually allow for anything in-game unless you use some sort of ( likely incredibly altered ) source port that supports that kind of thing.

Share this post


Link to post

Indeed, I was just trying to bust the myth that a set of vertexes with 2D coordinates, a set of sectors with floor and ceiling heights, and a set of linedefs with start and end vertex references and front and back sector references, allegedly couldn't represent some true 3D structures (particularly those involving overlapping), while in fact they perfectly can represent absolutely any 3D structure, except slopes and portals as I said. I didn't mean to say anything about the engine itself in this case.

Share this post


Link to post

That said, I'd imagine that the fact that sidedefs can only reference a single sector could get kinda fucky. Similarly, you might need to make it so that sectors are naturally subtractive, so anywhere a ceiling and floor with the same height overlaps there'd instead be neither.

Would be interesting to see a source port that could manage something like that, though, although I'd imagine it'd have to rewrite a ton of the core engine.

Share this post


Link to post
Arctangent said:

That said, I'd imagine that the fact that sidedefs can only reference a single sector could get kinda fucky.

Just stack multiple linedefs onto each other, all of them referencing the same sector on its one side, and multiple different sectors (ideally with floor and ceiling heights making them sanely ordered above each other) on its other side.

Arctangent said:

Similarly, you might need to make it so that sectors are naturally subtractive, so anywhere a ceiling and floor with the same height overlaps there'd instead be neither.

I'd rather allow them both to exist. Each of them just needs different neighboring sectors. The only problem would be "multi-linedefs" (described above) having overlapping sectors on its side with multiple sectors. Otherwise, sectors may safely overlap, which could be useful for creating impossible geometries.

But yeah, this is an idea probably best suited for a completely different engine.

Share this post


Link to post

Editors will merge and split geometry for you to keep things sane, but indeed the format itself doesn't prevent several vertices, lines, or sectors from overlapping.

In fact the very first port with room-over-room, imaginatively called RORDoom, used just this. If you wanted two different floors to occupy the same X/Y space, you had to make overlapping sectors. This didn't catch on, fortunately. It would have made editing a bit complicated.

Share this post


Link to post

So I've thought about it recently, and I realized that Doom is limited 3D. It has three axes, but they don't operate with the normal freedom associated with conventional 3D. X and Y can be used to generate two dimensional planes, which is more or less congruent with "fully" 3D rendering. However, Z is used not to connect vertices to X and Y but instead to vertically extrude X/Y shapes into an additional dimension, with either a positive or negative value in either direction. Thus, fully enclosed 3D geometry–cubes, prisms, spheres, or any Platonic solid really–is impossible, although there is still a wealth of complexity to the possible architectural shapes the engine can spit out.

 

No underlying geometry can normally be placed in the Z-space between the enclosures (the "ceilings" and "floors") of X and Y, but mid textures can imply additional architectural accents and of course advanced source ports can push what's possible with XYZ interactions, but the only fully 3D elements are the imported voxels and models sometimes used in mods. As far as I know, no ports can actually generate vertices to create enclosed structures between all three axes except for Vavoom which no one seems to be interested in modding for.

Share this post


Link to post

The only problem with calling it 2.5D is it's easy to confuse it with games that use 3D polygons on a 2D plane of gameplay that are also called 2.5D

Share this post


Link to post
49 minutes ago, Arctangent said:

It's also based entirely around the map format, not the actual game.

That's true, but at what point does the map stop becoming the "actual game"?  I believe you mean the engine is 3D, but the map format isn't.  But the "actual game" is those two things and everything else together.  

 

If I made a 2D platformer in idTech 6 it doesn't make it a 3D game just because the engine is.

Share this post


Link to post

I mean, I guess that depends on if you consider 3D floors and vertical interactive portals to be 3D despite UDMF being based around the exact same system of 2D vertices, lines, and sectors that the vanilla Doom format uses.

 

Granted, ZDoom UDMF is bit more ambiguous about that, because you can give individual vertices their own Z coordinate for slopes and you can do the same with thing heights, which makes Hexen the same kind of ambiguous to a lesser extent, but for the most part it is still 2D extrapolated to make a 3D world.

 

But that's the thing: after it's extrapolated, it's 3D, because it occurred after the 2D map format was transformed into a 3D world. Which seems a bit like stating the obvious, to be honest. As another example, Minecraft's map format is defined in 16x16x16 blocks - yet unlike in, say, Pokemon pre-3DS, your player character and all other objects in-game can move in intervals smaller than 16 map units, even though that space "within" the blocks don't exist to the map format.

 

Your "2D platformer in idTech 6" anecdote fits this perfectly: even in the levels themselves would ( presumably ) exist past the 2D plane in the map format, the actual gameplay only interacts with that 2D plane. In that case, it's the exact opposite of Doom and Minecraft; instead of the data from the map format being extrapolated into a more complex game world, the 2D platformer's game world is actually less complex than the map format would suggest, albeit the extraneous map data would probably still be used for aesthetics and such.

Share this post


Link to post

Doom wasn't 3D, i'm sure the game theorists got some things wrong but the creators have said it themselves that doom is fake 3D.

Share this post


Link to post
2 hours ago, Mega said:

Doom wasn't 3D, i'm sure the game theorists got some things wrong but the creators have said it themselves that doom is fake 3D.

I'd like to see a source for this. many people claimed that in the youtube discussion to the Game Theorist video but both Romero and Carmack recently stated otherwise, as you can see here in the thread.

Share this post


Link to post
18 hours ago, Arctangent said:

I mean, I guess that depends on if you consider 3D floors and vertical interactive portals to be 3D despite UDMF being based around the exact same system of 2D vertices, lines, and sectors that the vanilla Doom format uses.

 

Granted, ZDoom UDMF is bit more ambiguous about that, because you can give individual vertices their own Z coordinate for slopes and you can do the same with thing heights...

This is true, but keep in mind that in a traditional 3D space, you're able to freely move vertices around to literally any coordinate. In Doom, even UDMF or Zdoom editing mode doesn't allow much in the way of constructing geometry between the floor and ceiling of any given sector, although it can achieved in very restrictive ways. While the implementation of slopes does mean the Z-axis has more range, you're still tugging and pulling on 2D sectors that can be extruded in a limited way in 3D. You're not able to free construct spheres or polyhedrons, but you can create an extremely limited range of 3D structures. So ultimately if you don't have full access to all three axes, you're working with limited 3D, rather than "true" or "restriction free" 3D.

Share this post


Link to post

I came across the original video for the first time yesterday. There's a great research paper titled A Brief Summary of DOOM-style Rendering by Forsman & Kreimeier from 1996 that I came across on Google Scholar. I haven't got the link but I would suggest to read it if you can find it. 

*EDIT* more like just a piece of academic work than a piece of research

Edited by Necr0n0m

Share this post


Link to post

since this wasn't mentioned, here is another reaction video by Nerd Sauce from last year. this is more of a layman's contribution but shows that you don't have to be an expert to observe what the engine can do and to know which statements GT made can't be accurate.

 

 

 

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
×