Doom may have been intended to run at 70fps

Recommended Posts

The 0.4 version makes me think this. If the PC can handle it, 0.4 will run at 70fps. While it's true that the press release blurb indicated that id wanted to target 35fps even early on, I think that they tried pressing their luck with 70fps once the engine was in place and later decided to revert in order to be more accessible to players with weaker PCs.

1. Player movement

Note how the player movement feels a lot tighter and the bobbing doesn't look as retarded as it did in 0.5. That's because on a tic-by-tic basis (ignoring realtime), the max speed of the player is half of what it is in 0.5, meaning that there's less momentum to push you after you release the key. The double framerate meant that even that smaller slide felt "snappier".

The 0.5 version doubled the max speed to compensate for the halved ticrate. Unfortunately, they didn't bother to tweak the finer parts of the movement code, this is where the "icy" feel came from. Due to exerting twice as much momentum, the slide went further in distance, and the slow framerate made that slide far slower than it would have been before.

Likewise, they didn't bother tweaking the bobbing sensitivity. As far as I can tell, it's the same bobbing behavior, just being run twice as slow while exaggeratedly swinging the weapon due to the extra player speed even if it looked the same between versions when run in real-time.

2. Sector movers

They all run twice as fast on a tic-by-tic basis in 0.5 than they did in 0.4 (can only compare doors due to no lifts, but still). Again, if their target was 35 all along, why would they have seemingly designed their intended mechanics in 70?

3. 0.4 Version unreasonably sluggish when capped

Doom was being designed as a slightly slower-paced game back in that stage of development, but slow down some footage of the 0.4 version to half speed. Can you honestly tell me that the devs would've found this an acceptable pace even if intended to be generally slower? I highly doubt that any of 0.4's mechanics were designed with 35hz in mind.

4. Wolf 3D Ran At 70hz

Okay, I know, it ran on a far simpler engine and was thus easier to pull off. However, this does indicate that the id crew were interested in getting that framerate if they could.

Share this post

Link to post

I think I remember reading somewhere that 0.2 and 0.4 ran at a higher framerate than the versions that would come after, but I can't be assed to actually test that theory.

It most certainly does run faster. I simply made the OP to present some points that show that they likely intended it and wasn't just a result of being incomplete and lacking a framerate cap.

Mostly because of a conversation I had with Maes once where I was talking about the alpha engine, mentioned its framerate and he pointed out to me that id wanted to target 35fps in November of 1992. Given my analysis of the gameplay behavior, I'm pretty confident that they changed their mind about it twice.

Share this post

Link to post

If they ever had the engine running at 70 fps smooth at any point (maybe possible on their NeXT dev rigs, but not on any DOS machine in 1992), then the collision/movement code must have been very different.

The current one is already pretty dodgy and full of hacks that depend upon hardcoded movement speeds, and most formulae don't play nice with the fixed_t arithmetic. I tried implementing a 70 TICRATE mode in Mocha Doom once, by modifying all Thing speeds, distances etc. by a #defined constant factor (e.g. in 70 fps mode, distances per tic are divided by 2, while timings are multiplied by the same factor).

Monsters and Doomguy moved around very smoothly, but everything got very easily stuck in walls, and tricks like wallrunning didn't work anymore. Which came to no surprise, as I probably missed a lot of subtle hardcodings, and in a lot of steps halving distances led to a required precision which was too great for the formulae to handle.

Share this post

Link to post

I've heard that the movement code was rewritten between 1.1 and 1.2, so there's a good chance it was rewritten since the alphas. Another difference in the alphas is how momentum continues to be applied even if you hit a wall. I.E. you can be running against a wall and immediately zip forward when walking over the gap of an extruded corner. This still happens in the final against other actors, but it actually bothers to cap momentum when moving against a wall, meaning you have to accelerate again once you've slid past the wall.

It's worth noting that you can actually crash the 0.2 version by running into a wall too fast and going through it. I can most easily trigger it by using the keyboard and mouse simultaneously. I don't remember offhand if the following bit is actually true, but I seem to recall that there was no movement speed cap when using the mouse, while the keyboard did have its own cap.

gemini09 said:

I think it's more probable for that framerate to be a remnant of the Wolf 3D engine. If the DOOM engine was from scratch, then I guess you would be right.

The Doom engine was certainly from scratch. There was another engine between Wolf and Doom that ended up being used in Shadowcaster. None of these engines share code AFAIK.

Maes said:

If they ever had the engine running at 70 fps smooth at any point (maybe possible on their NeXT dev rigs, but not on any DOS machine in 1992)

Carmack said in an old interview that he estimates he could've gotten a 15% speed increase if he did the renderer in x86 ASM. Besides, if Tom had remained influential, the game probably would've come out in mid '94, so that gives time for consumer-grade hardware to become more capable.

Note that the old HUD was meant to increase performance with its small window size, especially the more closed non-0.2 version:

Hell, you could probably segment the screen into 5 columns. The lowest height ones on the sides (as the corner boxes cover that space on top), the middle height one in the center (mouthpiece occupies some space on bottom) with the remaining two areas showing full vertical height. That way, it's not only a smaller area, but you're not even rendering it in full.

There's also various performance options that were cut from the final. There was an extra-low detail mode that was not only half columns but also half rows. You were able to set flat detail at 3 levels: full, no ceilings, no flats.

Note how the alpha versions deliberately y-sheared your view downward, you did not look straight-forward like the final version. That would make the no-ceiling mode less of a loss since you see less ceiling in this perspective anyhow. It also kinda looks "aim-down-sights-ish" and would allow more of the cut-off weapon sprite to be used (probably why those cut-off areas exist to begin with, aside from how the weapon raised when firing like in Wolf before that was cut).

Share this post

Link to post

Monsters and Doomguy moved around very smoothly, but everything got very easily stuck in walls, and tricks like wallrunning didn't work anymore. Which came to no surprise, as I probably missed a lot of subtle hardcodings, and in a lot of steps halving distances led to a required precision which was too great for the formulae to handle.

I actually find this very surprising. My limited understanding is that doom uses a lazy kind of collision detection which only checks for obstacles at an object's destination, rather than sweeping a line or volume through the path necessary to get there. Hence bugs like this:

So if anything I'd imagine the collision would work better at a higher framerate, since the objects are moving far less every frame. If that's the case, maybe the basic algorithm isn't at fault and the variables used for the job simply didn't have enough precision or something. I don't know.

Linguica said:

I actually had never noticed that. Makes me wonder if Carmack had anticipated y-sheared looking up and down really early on, and it wasn't something thought up later by the Raven guys.

y shearing is a very intuitive hack. I'd be surprised if raven were the ones to "discover" it first. Carmack likely just rejected it in the end since it produced a far more flawed projection than he could really stomach.

Also this is a complete tangent, but are you guys familiar with that feature in one of the alphas that basically drops your viewpoint to the ground? Some people have called that a "prone" feature WIP, but I think that's extremely improbable. I think it's far more likely that Carmack put that function in to test that he was producing a proper floor projection, because I can speak from experience when I say that that is actually extremely tricky to get right when you're using two entirely different algorithms to draw wall columns compared to floor spans like doom does. All you have to do is be off a little bit and suddenly the edges of the floor don't meet the walls at the correct spot all the time, and it can drive you crazy making sure it just looks right in every situation.

Share this post

Link to post

Regardless of the thread title, I quite like talking about all aspects of the alpha versions and don't mind it being in this thread.

sheridan said:

are you guys familiar with that feature in one of the alphas that basically drops your viewpoint to the ground? Some people have called that a "prone" feature WIP, but I think that's extremely improbable.

Personally, I think it's likely that it was a halfway-removed no-momentum feature. Apparently there's some no-momentum mode in the final too (but have never used it). The view probably only drops to the ground because that's the actor origin and that the bobbing code in that version might be what sets the base viewheight.

Speaking of viewheights, the alpha had it at 40 instead of 41 as in the final. Go up to any 40-tall ledge and see how it goes right along the horizon line, not angled at all. They were probably satisfied with the height but didn't want to go any lower and didn't want to go too far away from it when attempting to remove the effect, so they added 1.

sheridan said:

y shearing is a very intuitive hack. I'd be surprised if raven were the ones to "discover" it first. Carmack likely just rejected it in the end since it produced a far more flawed projection than he could really stomach.

Marathon and ROTT were being developed at the same time as Heretic and all independently had y-shearing, so yeah I don't think it's worth crediting Raven for it.

Share this post

Link to post

Note how the player movement feels a lot tighter and the bobbing doesn't look as retarded as it did in 0.5. That's because on a tic-by-tic basis (ignoring realtime), the max speed of the player is half of what it is in 0.5, meaning that there's less momentum to push you after you release the key. The double framerate meant that even that smaller slide felt "snappier".

Even as it is in the final product, the movebobbing seems way over exaggerated, and I always thought it looked far better in the 0.4 alpha. I never knew the technical reason why it changed so much from 0.4 to 0.5, though.

I was stunned by how ridiculous it looked in 0.5 years back, if you attempt to SR50 in that alpha, the gun sprite can move WAY more than it should on screen, flying all over the place - If you attmpt to SR50 in the 0.4 alpha, the gun again moves more than it's supposed to, but because of how quickly it repositions when you stop, it still looks way better.

I'm glad there are others out there who have noticed all these revisional nuances.. I'm doubly glad that you guys actually have some technical knowledge, unlike myself!

I would love to see a ZDoom mod that accurately emulates the movebob and player movement behavior present in 0.4. I really like the 'tight' momentum and 'realistic' weapon bobbing, I'm wondering how it would feel in Deathmatch. (Come to think of it, doesn't Adventures of Square have reversed movebobbing that still remains "where it should", for lack of a better term? Would love to see this in more mods.)

EDIT: As far as the frame rate is concerned, which source port was the first to add optional increased FPS? Was it ZDoom, or did another port take a crack at it first? Interesting to think, in a different timeline, Doom was released at 70FPS - Although, I have a distinct memory of all Alpha versions of Doom being sluggish on rigs of yesteryear. I always noticed the difference of the movebob, but didn't notice the difference in frame rate until a few years later, on idfferent hardware.

Share this post

Link to post

For a short period, there was an experimental build of Risen3D that made the stop-pressing-the-button-slide of the Doomguy far more like the shorter stopping distance of more modern shooters.

I tried it for a while and it really took a lot of getting used to. Running around familiar maps was the most difficult where I was very used to exactly how the Doomguy-slide would propel me as I turned a corner or strafed into the open past a corridor entrance. The number of times I ended up shooting a wall instead of down a corridor was amazing.

Share this post

Link to post

Wow, now I am very curious. That could make an interesting gameplay element for some big TC that changes behavior of various things - perhaps something going for the more "survival horror" feel. Hell, such an element might be well placed in a "Doom3 in Doom2" type mod.

My last post probably sounded like I was against the idea. Sure, it was hard to get used to and in a fairly true to Doom environment it would not be great (IMO) but, in a TC or in the right kind of mod, yes, it definitely has possibilities.

Share this post

Link to post

Hell, you could probably segment the screen into 5 columns. The lowest height ones on the sides (as the corner boxes cover that space on top), the middle height one in the center (mouthpiece occupies some space on bottom) with the remaining two areas showing full vertical height. That way, it's not only a smaller area, but you're not even rendering it in full.

I haven't seen anyone mention it, so, here goes: There's a lump in the 0.2 wad that contains per-line x86 code to paint that region inside the HUD. In other words, that HUD is not an overlay - there was custom code for each viewable line! And, it was loaded from the wad, so custom HUDs were within reach. That would wreak havoc with today's processors with small internal code cache, but, it probably helped the 386 quite a bit. Pretty crazy stuff.

Share this post

Link to post

Note how the alpha versions deliberately y-sheared your view downward, you did not look straight-forward like the final version. That would make the no-ceiling mode less of a loss since you see less ceiling in this perspective anyhow. It also kinda looks "aim-down-sights-ish" and would allow more of the cut-off weapon sprite to be used (probably why those cut-off areas exist to begin with, aside from how the weapon raised when firing like in Wolf before that was cut).

I never noticed that. Everything in the alphas seemed to feel "bigger," but I thought that was because the player's viewpoint was closer to the ground.

Share this post

Link to post

I haven't seen anyone mention it, so, here goes: There's a lump in the 0.2 wad that contains per-line x86 code to paint that region inside the HUD. In other words, that HUD is not an overlay - there was custom code for each viewable line! And, it was loaded from the wad, so custom HUDs were within reach. That would wreak havoc with today's processors with small internal code cache, but, it probably helped the 386 quite a bit. Pretty crazy stuff.

Is that VIEWINFO or HIGHBLIT? Currently, the wiki says that their purpose is not known; so feel free to share more any information that you know and that is missing.

Share this post

Link to post

I actually find this very surprising. My limited understanding is that doom uses a lazy kind of collision detection which only checks for obstacles at an object's destination, rather than sweeping a line or volume through the path necessary to get there.

Indeed, that's a classic limitation one encounters when coding his first simple collision physics simulator, such as a pong variant or a "molecule vessel". It's almost as if those systems have a "universal constant", defined by the product of the time step and the maximum possible speed. If you exceed that, your little universe breaks ;-) I think we all tried that, at one time or another.

In Doom, the only major instance where this limitation becomes apparent is the Manc fireball, as you said, but it also subtly affects some other aspects of the game, like e.g. the door opening radius: faster moving monsters can open wider doors, to the point of activating the other side of the door by reaching for e outer linedefs, plus all those player "gliding" tricks etc.

However, for the player or monster movement, there's also some "fine positioning" code which is a complete kludge, and basically fidgets around with an object's position, especially when trying to slide along a diagonal wall. The worst offender is P_SlideMove, which affects the player, while monsters have problems of their own. In 70 fps mode, the player coud move noticeably closer to the wall (kinda like when you IDCLIP), and also get stuck easier.

I think most movement problems actually derive from everything being able to move so much closer to the walls and the not-so-precise arithmetic allowing things to become irreversibly embedded.

Gez said:

Doesn't EDGE run at 70 FPS? I think I remember reading something about how to define "half frames" in DDF.

You don't mean uncapped framerate interpolation, do you? Those techniques affect only the visuals, not the actual internal state of the engine, and they don't even need to be precise half-frames either: they can be e.g. 35/60ths of a frame or whatever.

Share this post

Link to post

That sorta implies this method is just inferior to sweeping volumes altogether. It's not really. Depending upon the circumstances, the simpler method can perform better than the more complicated method, and it's also much simpler to implement as well, so there are real benefits to using it as long as nobody breaks it with "high velocity" objects.

Maes said:

However, for the player or monster movement, there's also some "fine positioning" code which is a complete kludge, and basically fidgets around with an object's position, especially when trying to slide along a diagonal wall. The worst offender is P_SlideMove, which affects the player, while monsters have problems of their own. In 70 fps mode, the player coud move noticeably closer to the wall (kinda like when you IDCLIP), and also get stuck easier.

You may notice in at least some of the alphas the ability to slide down non-orthogonal walls was completely non-existent. It feels more like moving against a series of very small squares than bumping into a smooth and contiguous line, and you can get stuck easily if you "run against the grain" so to speak. I'm pretty sure this is what john was talking about when he mentioned using polar coordinates to test collision against lines in his doom source readme too, which actually was a very dumb decision as he pointed out himself. At the very least, he could have simply treated entities as circles and tested for collisions against lines in his BLOCKMAP with tangents like build did. It wouldn't have solved the problem with high velocity objects clipping through certain obstacles but at least it would've fixed wall running and the generally sticky feeling you get when bumping into anything but orthogonal walls.

Share this post

Link to post

That sorta implies this method is just inferior to sweeping volumes altogether.

Well, no algorithm is really "inferior" as long as it works correctly and has its niche uses (unless it's bogo sort). E.g. even Bubble Sort may be preferable to more sophisticated and efficient sorts in applications where there are "few enough" elements to sort, and its coding simplicity will be an advantage in terms of resources/programmer's time.

sheridan said:

Depending upon the circumstances, the simpler method can perform better than the more complicated method, and it's also much simpler to implement as well, so there are real benefits to using it as long as nobody breaks it with "high velocity" objects.

Well, that's just the thing: there's always somebody or something "breaking the rules". Even if in Doom they obviously devoted some effort in limiting max. default speed of many objects, there are quite a few cases that fall through the cracks.

Share this post

Link to post

Is that VIEWINFO or HIGHBLIT? Currently, the wiki says that their purpose is not known; so feel free to share more any information that you know and that is missing.

Can't remember, other than to say that yes, it's one of those two. If I had to guess, I'd say HIGHBLIT. I wrote a wad editor a few years back in VB 6.0, with full support for the alphas and beta, and I think I wrote a small disassembler for the lump. I'll see if I can get it working. If so, I'll post the algorithm I used along with some info. It about knocked my socks off when I realized that I was looking at x86 code in a lump!

EDIT: Ok, I just downloaded the alpha. I have my wad editor here at work, so I clicked on HIGHBLIT, and here's the output of my editor (brings back memories). Apparently, I did not finish the code, and I was trying to decipher a portion of it. It has 2 parts, first part is the x86 code, and I never figured out the second part. Here's what I got:

By the way, I'm not sure my tiny disassembler is working properly - I remember throwing it together, just to understand this lump. Here's the VB 6.0 source with the tiny disassembler, if it helps. Again, I'm not sure it's even correct, but it's close enough to verify that the lump actually does contain x86 code:

Please don't ask me what I was trying to accomplish in the second part - I was trying to figure out what it was for, but I never finished. Someone please provide another set of eyes - I find this approach fascinating.

By the way, why can't I place a code tag inside a spoiler tag? When I do, the spoiler ends up being empty.

I had to put the code tags outside of the spoiler, which is awkward. That's why I edited my post 100 times :) Oh well.

Share this post

Link to post

Well, that's just the thing: there's always somebody or something "breaking the rules".

No, there isn't. There are sometimes people that break the rules either because they don't understand them or because they are lazy, and neither of those things are necessarily the fault of the rules in question. The distinction here is important because if you actually come to the point where you expect people not to follow the rules you've set in place, then you're just going to start tumbling down the slippery slope of overly defensive programming, which is just inexcusably bad design.

Jaxxoon R said:

Is that the same reason why in the Genesis games Sonic would sometimes get trapped in walls if you went too fast?

Maybe. Every game is different. It's essentially impossible to say for sure unless somebody can dive into the game's source code or decompile the byte code in the cartridge to figure it out for themselves.

kb1 said:

Can't remember, other than to say that yes, it's one of those two. If I had to guess, I'd say HIGHBLIT. I wrote a wad editor a few years back in VB 6.0, with full support for the alphas and beta, and I think I wrote a small disassembler for the lump. I'll see if I can get it working. If so, I'll post the algorithm I used along with some info. It about knocked my socks off when I realized that I was looking at x86 code in a lump!

That is fascinating! Maybe the code stuffed inside VIEWINFO and HIGHBLIT was meant to act as a sort of lightweight collection of video drivers for the game?

Share this post

Link to post

I haven't seen anyone mention it, so, here goes: There's a lump in the 0.2 wad that contains per-line x86 code to paint that region inside the HUD. In other words, that HUD is not an overlay - there was custom code for each viewable line! And, it was loaded from the wad, so custom HUDs were within reach. That would wreak havoc with today's processors with small internal code cache, but, it probably helped the 386 quite a bit. Pretty crazy stuff.

Share this post

Link to post

Come on, man - it's elegant as hell :) Imagine having a differently-shaped HUD in every episode, or looking through a gun scope, or binoculars. It's done without conditional branching, so it's brutally fast. You can even avoid looping.

Back in the day I wrote some rendering code that would draw an entire line, then I'd dump a RET in the middle of it to control how long the line was (and, of course replace the code under the RET when the line was done. It was very fast, on my 486-50 :)

Of course, though, you're right. There was a time that people didn't do stupid shit like write viruses. It pisses me off to this day: "Hey, let's attack someone we don't even know, cause that would be cool." There's something wrong with a lot of people in the world...

Share this post

Link to post

Linguica said:
Makes me wonder if Carmack had anticipated y-sheared looking up and down really early on, and it wasn't something thought up later by the Raven guys.

I get the impression it was just "realistic" because when you walk you tend to look somewhat toward the floor to avoid stepping on anything dangerous or filthy. Maybe later they felt it wasn't worth it, perhaps because it caused some slight distortions or complications, or just to represent that the guy's head would move up sometimes, making the straight view the "average" viewpoint. If I'm guessing right and I had been there maybe I'd have suggested, "how about shearing the view a bit while walking and straightening it smoothly while shooting, being hit, dying or standing still?"

I haven't checked what the view height is in the alphas with the slight shearing, but in the released game the height is below the height of the face, so in a way it does give some impression that the view is "inclined".

kb1 said:
There was a time that people didn't do stupid shit like write viruses. It pisses me off to this day: "Hey, let's attack someone we don't even know, cause that would be cool." There's something wrong with a lot of people in the world...

Rather than just to be cool, a good deal of viruses are made as exploits to steal data, insert programs or disrupt a system, so it's not much different from waylaying or robbing strangers, which we have been doing since the dawn of history, ages before we had any electronic technology. They didn't do it before because they didn't know how yet or didn't have much to gain from it.