Why original Doom doesn't support mouselook?

Simple question.

I think, Doom engine made semi-3D area which can be shown easily. It's not a restricted area like Wolfenstein 3D (where mouselook would be unnecessary too) so I think the engine might be able to supoort looking up and down.

Why Doom engine does not support mouse look in the original versions?

PS.: I'm not good at C++ and any kind of programming, so please try to tell me the reason simply. =)

One word: Heretic. Same engine, less than a year of separation with Doom.

Now why they didn't do that in Doom...it would be interesting to see if the infamous y-shearing hack was something which was conceived 100% by Raven's coders (not unlikely, since they also added a lot of other features later on, while id had went full-force on Quake).

Of course, it might be possible that Romero, Carmack & co. were perfectly aware that it would be possible to throw in a similar hack, but then decided that gameplay-wise it wouldn't add much (and they had cancelled a lot of other ideas that later appeared in Heretic, Hexen and Strife, so,...)

As for "it can be shown easily"...not quite. Doom's engine isn't polygonal, so you can't actually look at walls with a wall-to-floor vertical angle other than 90 degrees, nor can you face the floor or ceiling directly (case in point, compare how mouselook in ZDoom/prBoom+ etc. looks like (in software mode) with how it looks with OpenGL (which IS polygonal), or even DoomBuilder's 3D preview (that's a completely different engine). Those engines actually have a proper geometric projection, and have a perspective that's quite natural.

What you see in Doom OTOH is actually more of a visual distortion which is applied a-posteriori, and which gives you the illusion of looking up/down: they actually compress the vertical distances in a non-linear manner, e.g. making stuff lower than your eyes shorter, and stuff at eye-level longer, in order to make the floor appear closer, rather than actually rotating a camera in 3D studio. What I mean is, a) it's a hack b) doesn't look all that great c) Doom did fine without it ;-)

The engine only draws vertical scanlike like thingies. They go from the bottom of the screen up. They cannot rotate.

It's kind of complicated but transformations are applied to 3d renders by matrices, which are usually 4x4 arrays. There are multiple kinds of transformations you can apply while 3d rendering, including scaling, rotation, displacement (transformation), skewing and other advanced stuff if you know how to fuck with matrices. All of these matrices are multipled together before being applied to, say, a model, or a triangle, whatever. It determines how they are displayed (if at all) on the screen.

Doom has almost nothing in common with modern 3d engines. To determine if it needs to render a wall, it will see if the pixel on the floor it begins at is within your field of view, and if it is, draw a column of pixels there. Then it gets kind of complicated juggling around all the other shit that display on screen too, like sprites, floors and other walls.

The Doom engine is basically a highly optimized way of drawing columns of pixels and it was a triumph of computing performance at the time it was released.

True 3d engines like quake, before the rasterization crap begins, interpret the game, data and world completely differently. As a true 3d engine, it uses matrices and fancy mathematical shit. It is approximately 26345 times more complicated than rendering a column of pixels.

Basically if you got in a time machine with a copy of quake and went to someone's house that can run Doom just fine, you will get quake to run at about 2 frames per second on their computer.

Doom and Quake didn't so much come out at the times they did because John Carmack is a smarty man, but because the timing was just right. Or, John Carmack jumped on it at just the right time.

The up and down looking you see in Doom source ports works within the realm of Doom's weird column rendering engine. There's nothing 3d about it, it just sort of distorts the columns of pixels, their projections and positions.

Did Romero/Carmack ever speak about the engine having such a potential capability, or was it something that the -apparently equally smart- guys at Raven found out entirely on their own?

There is mouselook already: move the mouse to the left, and the camera turns to the left; same with right.

Now for looking up and down. As I said elsewhere, Doom is a game that is barely 3D. It's just another thing that the Id guys Just Didn't Think About(tm). It's like being blocked by a cacodemon flying above you, or being able to activate a switch buried under your feet, or explosions propagating their blast damage as an infinitely-tall square pattern. It's like not being able to jump and crouch. Try to remember that the previous step in Id's history had been the cubemaze known as Wolfenstein 3-D and it should become clear why they Just Didn't Think About(tm) all these things. Did Wolf3D need looking up and down? No. Did it need jumping or crouching? No. Did it need over/under collision checks between things? No. Did it need to check the vertical distance for computations such as speed or blast damage? No. Then why would Doom have needed any of these things?

Doom wasn't 2.5D, it was more like 2.25D. Heretic got closer to the mark: Raven added actual under/over physics code, but there were some glitches and bugs. They've added the possibility to fly and look up and down.

Gez said:

There is mouselook already: move the mouse to the left, and the camera turns to the left; same with right.

My man, this deserves an immediate custom title "Gez on mouselook" with a link to the entirety of your post.

Probably a bit off-topic, but a while ago I put together a composite of several screenshots to show what was actually happening when you looked up or down with software rendering in Doom:

http://img843.imageshack.us/img843/1893/vpanflook.png

Kinda cool, but not too surprising.

Sorry Gez but I have to completely disagree with your diagnosis of DOOM and your suggestion that the reason it is "2.5D" is due to any other reason but that perspective correct projection, of a textured 3D world, in a software renderer, simply was not viable at the time. Such a renderer was neither viable computationally, financially (investment needed to build the technology) nor play-ably back then.

I would suggest that it is far more likely that the DOOM engine was built in full knowledge of the limitations of it's design.

Besides which, its not like Heretic exploited the additional range of visibility they gained. In fact, I rather think it detracts from the experience. Rather like taking a movie and forcing it into "3D" for no other reason than because its possible and a good way to differentiate the new experience from the old in the eyes of the consumer.

That's why I handily cited a number of other elements of Doom's flatness that have absolutely nothing to do with perspective correct rendering, or even rendering at all. Were things such as this a consequence of restrictions in computational power?

But besides, Heretic's system requirements aren't that much higher than Doom's, despite having over/under checks and Y-shearing.

You are conveniently failing to consider that they had not already discounted it prior to any notion of gameplay mechanics becoming relevant.

Heretics failed attempt at 3D physics is just that; a failed attempt to bolster an inappropriate mechanic on top of an engine design not intended to support it.

y-shearing is more computationally expensive. However that is irrelevant to the argument I'm making, "Quantum Lost Soul movement" even more so.

It is really pretty strange that id Software didn't implement Heretic's over/under physics and Y-shearing code into Doom 1.3, given how heavily they used large-scale vertical designs in Doom II's maps.

DaniJ said:

y-shearing is more computationally expensive. However that is irrelevant to the argument I'm making, "Quantum Lost Soul movement" even more so.

Actually Heretic was pretty playable on similar specs to Doom, if not a bit faster at times. I wish I could say the same about other contemporary games like Descent, ROTT, Duke Nukem 3D or Quake.

I think I'm being misunderstood. I am not suggesting that the reason y-shearing was not implemented was due to the additional computational power needed for it (as it is actually pretty marginal). Rather I was suggesting that the reason DOOM is entirely 2D with a kinda-3D drawing component is that doing it all in full 3D was not viable. Thus they made no attempt to make it behave as such.

I argue that the lack of these elements in DOOM is a conscious design decision due to the inability to implement them the Right Way (or they were deemed unnecessary).

The way I see this having played out goes something like the following narrative:

Heretic Designer: It would be cool to give the player the ability to fly.
Heretic Coder: Yes but the renderer doesn't support looking up/down... hey Carmack, can this be implemented?
Carmack: Not really, DOOM is essentially a 2D engine.
Heretic Designer: But its hugely important!!
Carmack: Well, I guess you could y-shear and implement a few simple tests in the collision checking.
Heretic Designer: Sold!

Doom's guts are 2D, but it's displayed in a 2.5D. The automap is what Doom really is, it's just cleverly represented as a series of tiles with height variation.

In Doom you see things in two-point perspective, that is, perspective lines coming to a point on the far left and right sides. You'd need three point-perspective to truly look up and down. Notice that in vanilla Doom, or in the software rendering mode of a source port, the vertical columns never become diagonal like they do in 3D games.

When you think about what the technological possibilities were in late 1993, no one was trying to implement vertical aiming. The earliest shooter I can think of to have vertical aiming was Rise of the Triad in 1994.

As clever as Carmack has proven himself, keep in mind Ben Gokey and Chris Rhinehart (the former especially apparently) were no simple code monkeys. Ben invented polyobjects, whereas everyone up until then (and even afterward if they weren't aware of Hexen) claimed it was impossible to have moving walls implemented efficiently within a BSP renderer.

They also coded a full compiler and interpreter for an ad hoc scripting language, which is no small feat on its own.

Indeed but those developments came about after Heretic. Its certainly possible that the y-shear was something the Raven coders figured out but I wouldn't immediately think to attribute them with it.

Also, polyobjects as they appear in Hexen aren't actually that impressive. They simply realize that so long as one does not break the rules of the BSP and the sorting method used - that they can have dynamic geometry within a single subsector.

Quasar said:

They also coded a full compiler and interpreter for an ad hoc scripting language, which is no small feat on its own.

While I'm sure they deserve the amount of credit you're giving them, keep in mind that ACC is not really that great of a compiler. In addition the ACS byte code seems to be designed to simplify this task quite a bit.

Lookup/down adds a whole extra fourth axis to the interface. Assuming it was considered, my guess is they preferred to keep the game controls as simple as possible; autoaim is "good enough".

DaniJ said:

Also, polyobjects as they appear in Hexen aren't actually that impressive. They simply realize that so long as one does not break the rules of the BSP and the sorting method used - that they can have dynamic geometry within a single subsector.

It was still a progress. And:

Blzut3 said:

While I'm sure they deserve the amount of credit you're giving them, keep in mind that ACC is not really that great of a compiler. In addition the ACS byte code seems to be designed to simplify this task quite a bit.

You guys don't know where to be thankful and give credit. Even if such features don't appear so great or complex today, keep in mind that they worked just fine and did their job. Also I'm pretty sure that ZDoom still thrives on an advanced version of ACS. And how popular is ZDoom?

The way I look at it is, yes ACC is simple, but it's still twice as far as I've ever gotten with a compiler ;)

printz said:

It was still a progress.

Perhaps from a player's perspective yeah I guess it can be considered progress. However from an engineer's perspective its no progress at all.

Hexen's polyobject implementation did not achieve anything on a technical level that wasn't already known. It might not have appeared in a commercial game before Hexen, however there is an entire field of research called Computational Geometry that had been exploring this stuff that dates back to the early 70's.

I resent the fact that you say I don't know where to be thankful and give credit, when in reality, pretty much all of this tech had already been explored long before it was popularised by game engines.

The people that deserve credit are the likes of Henry Fuchs, Thibault and Naylor and in DOOM's case, Gordon and Chen in particular. The last two published a paper in 1991 describing their method for efficiently rendering BSPs that is effectively the same as that used in DOOM.

So yeah, I do know where to be thankful and give credit :P

Also, there's the issue of hardware requirements. DooM was heavily optimized to run on 386. 486 was the recommended processor, yet many DooM 2 levels run at 30ish FPS with 486 SX/33. Just because there is possible to add features or hacks today doesn't mean they would be feasible decades ago.

The y-shearing trick actually isn't very different than "normal" rendering: Doom uses some precalculated arrays to define the geometry of what the player sees (e.g. vertical and horizontal FOV) and what screen scanline/column corresponds to what view angle. It's thus possible to change what and how much of the "world" the player sees just by altering the values in those arrays on-the-fly (on every frame, if necessary). If you alter them so that the y field of view does not go from -45 to 45 degrees but from 0 to 90, that's all that's needed to change, and the engine will handle the rest quite transparently.

From Heretic's source code, in P_SetupFrame() (after some Javisms, sorry):

int tempCentery = viewheight/2+(player.lookdir)*setblocks/10;

if(centery != tempCentery)
{
centery = tempCentery;
centeryfrac = centery<<FRACBITS;
for(i = 0; i < viewheight; i++) {
 MyPlanes.yslope[i] =  FixedDiv((viewwidth<<detailshift)/2*FRACUNIT,
 Math.abs(((i-centery) <<FRACBITS)+FRACUNIT/2));
 }
		
}

Nothing else is changed in the rendering process (other than some adjustments for sprite positions and some sanity checks here and there), so the only real overhead is recomputing the yslope array every time the player view actually changes (if you use full mouselook, this means potentially every frame).

Some descriptions of y-shearing being done by "rendering a bit outside of the screen" are bullshit. The Doom engine only computes the pixels that you actually get to see on the screen, none less and none more (save rounding errors), so just changing the yslope values won't result in it doing even 1% extra work per frame, even on a 486.

I have no doubt that John Carmack could have figured out y-shearing and implemented it without a huge amount of work if he had wanted to.

I think you have to put it in the context of the time, though. Doom was already a groundbreaking game at the time. None of the previous 3D games they developed (Wolf3D, catacomb, etc.) had it as a feature. They obviously wanted to get the game finished and released as quickly as possible, and Carmack probably had a bunch of other more useful features he was working on getting finished - stuff like multiplayer, for example.

Bear in mind as well that mouselook is something the game really needs to be designed for from the start of development - it's sort of like asking "why can't you jump in Doom?" - answer: because it would potentially break half the levels.

Finally, the way it works is a rather nasty hack, and the results can be quite ugly at extreme angles. You certainly don't get the same "fluid" movement that you get with a "true 3D" engine like Quake. If you're going to limit the angles you can view at to a small range, why not make things simple and just limit it to a single angle - the one where it always looks good?

fraggle said:

None of the previous 3D games they developed (Wolf3D, catacomb, etc.) had it as a feature.

That.

There was the notable precedent of Ultima Underworld, of course, but that was not what Carmack had in mind. Quite the opposite, he was dead-set on producing a faster engine than that particular game (but equal or superior in the "eye candy" factor) and so came up with a set of optimizations and tradeoffs.

Tradeoffs which, as it would be amply demonstrated, were well worth making. If Doom was like Duke Nukem 3D or Descent with a fully polygonal, texture-mapped engine since late 1993, it would simply be unplayable on the average PC or be restricted to a postage-stamp sized screen like Ultima Underworld, and would have to be an entirely different game, pace-wise.

Also, yeah, Carmack could probably have thrown in Heretic's (embarassingly simplistic) hack himself. But as Heretic showed, none was particularly impressed by it, so Doom didn't really miss much. People who wanted real 3D (and pay for the performance hit) would play Descent, or wait a few years and play DN3 and Quake.

It's quite believable Carmack didn't want that hack in his games. I recall another situation when people were playing DooM 3 at his office, on new 16:10 monitors. He started bitching about it saying the game is not adjusted for it, and primitive transformation from 4:3 to 16:10 has artifacts.

And besides, mouselook looks dumb, even on advanced ports.

DeathevokatioN said:

And besides, mouselook looks dumb, even on advanced ports.

I don't think so. I can't play without mouselook. PrBoom is the only source port where I agree the lack of mouselook.

With mouselooking, in GZDoom the sprites either move up and down which looks quite laughable and reminds you that your playing a 2d game, and if you do that thing that disables Y axis sprite rotation, the way you walk over sprites look when you stand on higher ground and stare down at them also looks quite bad. And in Software mode the screen shearing is just nauseating and I remember getting physically ill when I first picked up Doom again and used to try play with vertical mouselook. So yeah, that is a clever move on id's part to not include it. I also play Heretic and Hexen without mouselook, even if it makes certain situations more challenging.

TBH, I didn't know Heretic didn't support mouselook until just now. I play with it as little as possible. This stems mostly from the fact that I always set the mouse to 0 for vertical movement as I have a very sporadic approach to playing Doom-based games. With mouselook, I could go form staring at the ground to the sky in .5 seconds without even knowing wtf I just did.

I only use mouselook in WADs where it is specified.