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

There were fully 3D engines (in the strictest sense) before and after Doom -those that came before were usually untextured polygonal engines used in flight sims and the such, but a purely polygonal engine put a lot of challenges. Just to mention a few:

  • Poor visual results -you needed a quite high number of polygons and/or very skilled 3D artists to realistically render pretty much anything in an acceptable, recognizable manner. Vehicles, planes and simple buildings were already so-so, humans, animals and monsters just looked rough-cut and ridiculous, even with later polygonal games such as Fade To Black.
  • Collisions performed purely between polygonal objects in a 3D environment were computationally expensive -Doom, unlike sims, had a completely different internal representation of its world than what a compromise between
  • Depending on the kind of game, the theoretically infinite motion and rendering flexibility of a pure 3D engine might not be much of an advantage: e.g. for a flight sim you surely wand 6 DOF, rotating camera views, etc. but for a "stiff" driving simulator already you could do away with XY-axis rotation in many cases), for a dungeon crawler game like Ultima you probably don't need player view rolling etc. so the overhead of a full 3D engine worked against gameplay speed/fluidity.

I once wondered how Doom would've been received had it been released with a truly 3D, but polygonal engine, everything else about the gameplay being equal.

Terminator (DOS, 1990)


Robocop 3 (DOS, 1993)


Not so great looking, are they? And the second game is from the same time as Doom. Even with many more polygons, it would still look like crap, and play even worse.

Doom managed to strike a good balance by avoiding the complexities of a pure 3D engine, by mixing a mostly 2D internal representation with a constrained 3D rendering which, however, looked much better than anything else at its time, and played much better too. Going full 3D in all aspects of the engine and rendering wouldn't have given it much of a further advantage vs other games of its time, and in that sense id made the right choice/compromise. After all, if they wanted, they could just have licensed/copied Ultima's engine, but they didn't. Why?

It also set a precedent for Duke 3D and Quake -that you don't need to go full 3D in order to make a successful FPS game. Did anybody care about the lack of player view rolling in Duke 3D? Even in Quake, can the player's view roll on demand? Nope, it's pretty much constrained in Doom/Heretic style, so in that sense, the engine is normally underutilized.

Share this post


Link to post
scifista42 said:

Now, you can construct any 3D structure in Duke3D (I think), but not render any 3D structure (anything that involves room over room in the same column is unrenderable), which makes using unlimited 3D structures within the game extremely inconvenient, to put it mildly. I'm not sure if the engine crashes or just visually glitches when it tries to render such a scene, but either way, it's not what I'd expect of a "true" 3D game.


eDuke32 had a very interesting method of tackling this, simply layering rooms over rooms on top of each other to give the appearance of it being fully 3D. Honestly, I consider it a vastly superior method to Doom's more hacky 3D floors but that's probably because Duke 3D's engine is portal based so such a thing is more feasible, whereas portals in Doom tend to have more problems with the AI. The downside is that you can't move them individually below or above the merging point and you can't make new solid objects so you have to plan it out ahead of time before you make the extension.

Share this post


Link to post

Sometimes you have weird hybrid engines like Dark Forces, which feature two renderers working at the same time. A Build-style portal-based 2.5D renderer, and a fully 3D polygonal renderer. The latter is used only for a few select things (like the Moldy Crow and the mouse bots) while the former is used for pretty much everything.

Share this post


Link to post

Much like Quake for the Sega Saturn, it uses the PowerSlave Engine so it's technically 2.5-D in the same mold as Doom (Hence the environments being drastically simplified in movement compared to the PC and N64 versions) but with 3D objects and actors.

Share this post


Link to post
MetroidJunkie said:

Much like Quake for the Sega Saturn, it uses the PowerSlave Engine so it's technically 2.5-D in the same mold as Doom (Hence the environments being drastically simplified in movement compared to the PC and N64 versions) but with 3D objects and actors.


The PowerSlave/Exhumed engine (also known as the 'Slavedriver' engine) could do slopes, floors above floors, did not have infinite-height actors in any capacity. Also had dynamic lights and lightmaps -- it was indeed closer to the Quake engine than the Doom engine (despite still rendering in quads as per the Saturn's limitations).

No idea how you're getting "2.5D" there, unless you're confusing it with BUILD. Which, by the way, as far as I know Dark Forces used neither.

Share this post


Link to post

Then why were the Saturn versions of Duke 3D and Quake respectively so gimped compared to the PC (and, indeed, other consoles') versions? It clearly couldn't do horizontally moving sectors since that was one of the biggest omissions in those two games on the Saturn.

Share this post


Link to post

Both were created from the ground up using SlaveDriver; often recreating assets (such as resizing textures) to fit; on a platform that had no business running the things. Back in the day, it was seen as miraculous, especially given the performance differential between Saturn and Playstation Duke 3D and Quake's no-show on the Sony format.

Join us on next week's show for "why did the Sega Game Gear version of Sonic the Hedgehog lack parallax scrolling layers, and does this actually make it a 1.5D game?". ;)

Share this post


Link to post
Maes said:

I once wondered how Doom would've been received had it been released with a truly 3D, but polygonal engine, everything else about the gameplay being equal.


Cool thread, I missed that train, and rather than necroing it: I think texturemapping has a lot to do with how precise you can maneuver in Doom. A polygonal engine with the same maps running in the same speed as Doom might be disorientating, for instance in larger areas, where the pixels aren't scrolling by to let you know how fast you're going and there might be few, less explicit, shading gradients that could reach your view. I think polygonal Doom would have been successful but no longer alive today the way it is.

I mean, look at ellipsoid games like Ecstatica, which were lauded as the best thing since sliced bread back in the day, now but a corny footnote to most:

http://vignette4.wikia.nocookie.net/ecstatica/images/f/f7/Ecs_firstencounter.jpg/revision/latest?cb=20120813160048

Also, if Doom wasn't texturemapped, you'd have missed out on those fantastic sky "portals". Who can forget the first time they gazed out over those misty gray episode 1 mountains, awed at the possibilities?

Share this post


Link to post
Jayextee said:

Both were created from the ground up using SlaveDriver; often recreating assets (such as resizing textures) to fit; on a platform that had no business running the things. Back in the day, it was seen as miraculous, especially given the performance differential between Saturn and Playstation Duke 3D and Quake's no-show on the Sony format.


I'm questioning why those limitations specifically, the Saturn version of Quake actually has more complex geometry than the N64 version (Of which I'm pretty sure is a more direct port of the PC version), yet can't do certain things that a polygonal engine can use, its doors aren't even slanted which makes it seem as though it's not really using polygons to render out its environments.

Share this post


Link to post

Hmmmm... technically, couldn't Doom be considered 4D since it requires height, width, depth, and time to function as a game? (Similarly, wouldn't most movies already be 3D, with those that require glasses for depth being 4D?)

/troll

Share this post


Link to post
MetroidJunkie said:

its doors aren't even slanted which makes it seem as though it's not really using polygons to render out its environments.


Technically it's not, really. The Saturn didn't do polygons traditionally, more like resizing and skewing square sprites to act as quads (squares instead of the conventional triangles). I think, anyway (my technical knowledge is pretty average). Certain design choices may have been made around this, sure. As for anything else (you cite moving sectors in a previous post) I couldn't say for sure; but would guess that anything computationally-intensive that could've been a bottleneck on the already-struggling Saturn would have been dropped or simplified -- example that comes to mind is the rotating turbines on Death Row in Duke 3D -- they're static on the Saturn version.

Share this post


Link to post

Quads are still polygons, though, just 4-sided ones, and I know this because Blender offers quad polygons as a default to more easily place subdivisions into them. If what you're saying is accurate, then how are they really polygons? Moreover, how would it be able to have 3D models for the enemies and objects if it was merely square sprites that can't rotate or really move much at all which those things can clearly do without any difficulty? Clearly, it's 3D polygons inside environments that are more similar to Doom or Duke 3D.

Share this post


Link to post

Great rebuttal man. You explained your points well, though I'd like to have heard an explanation for how it is that actors can't move over or under each other while projectiles can. Jayextee gave a good explanation for it on the first page, though.

I think the original video author should've done more research before uploading, and concerned themselves less with youtube hits.

Share this post


Link to post
MetroidJunkie said:

...how would it be able to have 3D models for the enemies and objects if it was merely square sprites that can't rotate or really move much at all which those things can clearly do without any difficulty? Clearly, it's 3D polygons inside environments that are more similar to Doom or Duke 3D.


Clearly it's not. It's well known Slavedriver (the engine used in Powerslave, Quake and Duke 3d on Saturn) is a fully 3d engine. Just because some turbines aren't spinning around (which Jayextee admitted could be due to any multitude of reasons) or doors aren't slanted is not cause to jump to your conclusion about the method of rendering employed in these games.

Fun fact, the Saturn's VDP1 design was the basis of the first Nvidia 3d accelerator, the NV1. This also used quads, but the VDP1 ran circles around it in raw polygonal performance. :)

Share this post


Link to post
Jayextee said:

Both were created from the ground up using SlaveDriver; often recreating assets (such as resizing textures) to fit; on a platform that had no business running the things. Back in the day, it was seen as miraculous, especially given the performance differential between Saturn and Playstation Duke 3D and Quake's no-show on the Sony format.

Join us on next week's show for "why did the Sega Game Gear version of Sonic the Hedgehog lack parallax scrolling layers, and does this actually make it a 1.5D game?". ;)


Quake II however...amazing for a PS1 port.

Share this post


Link to post
Use3D said:

Clearly it's not. It's well known Slavedriver (the engine used in Powerslave, Quake and Duke 3d on Saturn) is a fully 3d engine. Just because some turbines aren't spinning around (which Jayextee admitted could be due to any multitude of reasons) or doors aren't slanted is not cause to jump to your conclusion about the method of rendering employed in these games.

Fun fact, the Saturn's VDP1 design was the basis of the first Nvidia 3d accelerator, the NV1. This also used quads, but the VDP1 ran circles around it in raw polygonal performance. :)


If it's a Fully 3D engine, how come the environment can't do even the most basic of horizontal movement, in either Duke 3D or Quake? There's literally nothing to suggest the environment is padded out with polygons, especially since it would be pushing more polygons than the N64 since the environments are more detailed compared to it and the PC version.

Share this post


Link to post
MetroidJunkie said:

If it's a Fully 3D engine, how come the environment can't do even the most basic of horizontal movement,

Movement isn't dimension. I've tried to explain it before.

Share this post


Link to post
MetroidJunkie said:

If it's a Fully 3D engine, how come the environment can't do even the most basic of horizontal movement, in either Duke 3D or Quake?...


I don't know what to tell you man. The engine is well documented in emulation and retro communities. It's plain as the sun in the sky anyone playing or observing the game that Slavedriver is fully 3d. As far as engine movement goes, you're wrong again as E3M4 on Saturn Quake has it's moving platform the player has to ride around on in one sequence of the level and it's horizontal movement is fully intact. Powerslave also has several moving objects within the engine. The only thing I've not seen is rotational movement.
Even Saturn's trademark rendering issues are present, including quad splitting on surfaces and distortion/squashing of sprite textures as their vertex origins move past the camera, though due to the expert programming of this engine this is minimized. Not to mention dynamic light sourcing/diminishing which is a dead giveaway.
Lobotomy wrote this engine specifically for the Saturn's unique hardware, to power these complex games where directly porting Build or idtech2 would have been impossible or massively inefficient. As far as the N64 goes, what do you want me to say? I always thought it looked like shit. :P

Share this post


Link to post

We clearly have some kind of endless fascination of pseudo-3D. I love learning about the technical details of these sorts of things. I'm reminded of the bizarre but beautiful engine used for the cancelled Sonic game for the Saturn, Sonic X-Treme.

Share this post


Link to post
scifista42 said:

Movement isn't dimension. I've tried to explain it before.


I meant polygonal, it wouldn't have that handicap if it was polygons, which the items and enemies are FULLY capable of rotation so clearly, they're rendered with different methods unless you think making polygons move is just super engine intensive, even though they managed to make the environments more detailed without a problem. They used polygons for the objects and a more Doomish method for the environments, hence why it managed to be more complex in geometry than the N64/PC versions and I doubt the Saturn was more 3D capable than the N64.

Share this post


Link to post
MetroidJunkie said:

They used polygons for the objects and a more Doomish method for the environments, hence why it managed to be more complex in geometry than the N64/PC versions and I doubt the Saturn was more 3D capable than the N64.


Alright I'm going to try one more time, even though I've had more fruitful conversations with a brick wall:


Interview from Gamefan, with the creators of the ports of Duke3d and Quake explicitly stating that yes, their engine is full 3D.
http://www.whipassgaming.com/genesisreviews/powerslave/dukenukem3d.html


Interview, also from Gamefan, with Lobotomy Software on modifying Slavedriver with new techniques for making the Quake port as awesome as possible:
http://www.whipassgaming.com/genesisreviews/powerslave/quake.html


And finally, Quake on Segaretro, referring to the well documented and fully 3D engine, Slavedriver. Are we done now? Can you please stop with this nonsense?
http://segaretro.org/Quake

Share this post


Link to post
MetroidJunkie said:

They used polygons for the objects and a more Doomish method for the environments


The way Slavedriver did environments was closer to Quake than Doom, bruh. Lightmapped, true rooms-over-rooms, slopes, etc.

As for the polygon enemies in Saturn Quake, don't give them too much credit; they were fullbright.

Share this post


Link to post
Use3D said:

Are we done now? Can you please stop with this nonsense?


He could still argue that it didn't look convincingly "fully 3D" ;-)
No true Scotsman

Share this post


Link to post

I'm just curious as to why things like moving train cars aren't in the Saturn version of Duke 3D (And similar things are absent in Quake), is horizontal movements in environmental polygons really that difficult? I'll remind you that the enemies in Quake (and items) are fully polygonal and can move around with full rotations without any kind of trouble so the notion that the quads are incapable of such movement is absurd. Outside of purposefully gimping the environment's movements, I can't imagine why they couldn't.

I'm going to quit saying "true 3D" and start saying polygonal. If the environments are fully polygonal, why can't they do movements that are clearly present in the enemies and should have been child's play considering their compromises aren't exactly more simplistic in a polygonal sense?

Share this post


Link to post

You're using a non-polygonal engine's features as an argument for another engine not being polygonal because it doesn't have them? Don't you see how self-defeating that is? Those train cars are portals.

Share this post


Link to post

In the case of the Sega Saturn, you also have to take the total limitations of the hardware into account: the Sega Saturn was essentially like a Sega 32X (so 486DX/40 levels of general purpose CPU power) with a permanent Sega CD, a 3D accelerator and 512K of RAM cobbled on.

Compare that with even an entry-level PC having 8 or 16 MB of RAM at a time. Essentially, the same limitations that precluded a full Doom version than appearing on either the PSX or the Saturn at the time, were also at work for Quake and Duke3D. The 32X kinda-sorta got away with it by "cheating" and substituting more RAM/HDD storage with ROM storage, something the Sega Saturn couldn't use, and in that game the limitations of the on-board CPU processing power were painstakingly obvious.

The fact that there was a (kinda-sorta) hardware 3D acceleration in the Sega Saturn didn't help more than that: content in both Quake and Duke3D had to be cut and simplified since it simply didn't fit within the TOTAL system constraints, period. A system with the processing power of a 486 and less RAM than a 286 AT wouldn't be rescued just by adding a (dubiously effective) 3D accelerator.

So if features like trains or whatnot were missing from the finished product, the causes must be sought elsewhere. The graphics engine is really the last link in the chain, and by no means the weakest, in the case of the Saturn and even the PSX.

Share this post


Link to post
MetroidJunkie said:

If the environments are fully polygonal, why can't they do movements that are clearly present in the enemies and should have been child's play considering their compromises aren't exactly more simplistic in a polygonal sense?

The reason that polygonal map geometry is subject to different limitations than enemies with polygonal models is typically collision detection. Polygonal enemy models typically aren't used for collision detection at all, they're visual only. Instead, the enemies have (invisible) simple box-shaped or cylinder-shaped hitboxes used for actual collision checks against each other and the map geometry*. On the other hand, polygonal map geometry tends to actually check collisions per each polygon, which is a tad more demanding and requires a tad more coding to handle such collisions for arbitrarily shaped geometry. The engine might disallow certain kinds of movement because it doesn't contain the elaborate code necessary to handling all possible collision checks related to those kinds of movement.

In other words: Consider that enemy models can only be processed by the renderer, whereas map geometry has to be processed both by the renderer and by the physics code. Therefore, for the purposes of the physics code, an enemy can be represented simply by coordinates of a single point + the size of a hitbox (of a simple symmetrical shape that is always the same), whereas map geometry has to be represented by coordinates of many points + a list of many polygons (with arbitrary shapes and sizes and positions and sloped-ness and all). Handling the former is definitely more simplistic that handling the latter.

*In some engines, enemy models might be used for collision checks against bullets and projectiles only, but then it's likely to be the bullets and projectiles themselves to have simplistic hitboxes used for their collision checks. Non-simplified handling of physical interaction between 2 objects, each of which is defined as a large bunch of polygons, is such a computationally-hard and time-demanding problem that real-time engines typically avoid it either completely or at least as much as they can.

Share this post


Link to post

Thank you, scifista, now it all makes sense. From what Maes is saying, it sounds like Sega screwed the pooch big time with a system that wasn't equipped much if at all to do polygonal 3D, unlike the Ps1 and N64. Supposedly, the reason Quake 1 didn't go on the Ps1 was because Sony didn't want the same game as Sega so they just got Quake 2. Seems kind of stupid, they could have just gone the N64 route and received both.

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
×