Why didn't vanilla Doom (DOS) get affected by the CPU advances like other games?

[printz]

On several games such as Quake and Descent, trying to play now, either on DOSBox or a DOS-compatible system, the speed is ridiculously accelerated. Older games like Supaplex also have this problem (and that happened so much sooner to them). 

 

But Wolfenstein 3D and Doom run excellently even now -- they have always had a stable frame rate. What did they manage which other games failed? 

[Smouths]

Been wondering about this too actually, especially in regards to Descent. Been having problems trying to get these two games running on my recently dusted off and un-retired Pentium II 266. Quake at least has WinQuake, which mitigates the issue, but that's not the case for Descent, which is made all the worse by the mouse's CPU cycle dependent implementation. I can either use something like throttle.exe to slow the CPU down and reduce the framerate, or use the experimental 640x480 mode, which the system doesn't handle very well.

[Aaron Blain]

That's interesting. I never would have guessed that would happen with games from those years.

 

My understanding is that in early days, not only did you have a good idea of how fast the target cpu was always going to be, but I'm assuming you didn't want to waste any cycles checking the clock time each loop to see if enough time had elapsed to tick the game logic forward. I don't know of any reason why evaluating delta time and maintaining a constant game logic speed would have been, technically, impossible in any era. Anybody have any more hands-on knowledge of this old architecture?

 

Maybe these are instances of Carmack being especially thorough? Just a guess.

 

One of my favorite RPG's is Wizard's Crown. I have to throttle the CPU way way down to get the icons to clomp around with appropriately satisfying chunkiness.

[Phobus]

The game time is dictated by an internal timer, locking everything to 35 tics per second. I have to assume the timer is actually checking against time on a system clock, rather than something subjective/variable like the CPU, which a lot of older games definitely do (One Must Fall 2097 even tried to mitigate against this with a game speed slider... Little did they know how far that slider would need to go now...)

[Redneckerz]

One possible answer would be that a lot of games ran in Real Mode, which is tied to the hardware clock. Doom however runs in Protected Mode. A DOS Extender was needed.

[dr_st]

Has nothing to do with real vs protected. It's just a matter of how the timing routines were implemented. Some developers did so in a CPU-speed-sensitive manner, and others knew better.

 

There are plenty of real mode games that run at exactly the same speed, on any CPU. Take, Alleycat, the 1984 marvel, for example. On the other hand, Descent is a protected-mode game, but the ship-bobbing code is still tied to the CPU clock too much.

[dpJudas]

It is about variable rate process vs fixed rate.

 

In Descent and Quake the playsim ticks after each rendered frame. When they developed the games the framerate was somewhere in the 10-75 fps ballpark. Now these games can reach thousands. The code was basically never tested against the case where delta time got so low. Likewise in UT99 the threaded code was never tested on an actual multicore CPU, so it broke when exposed to it.

 

In Doom everything is locked to 35 fps, which the developers at id might even have managed to reach themselves. That's essentially why Doom doesn't behave erratically - it never attempts to slice time into less than that.

[Redneckerz]

Just now, dr_st said:

Has nothing to do with real vs protected. It's just a matter of how the timing routines were implemented. Some developers did so in a CPU-speed-sensitive manner, and others knew better.

 

There are plenty of real mode games that run at exactly the same speed, on any CPU. Take, Alleycat, the 1984 marvel, for example. On the other hand, Descent is a protected-mode game, but the ship-bobbing code is still tied to the CPU clock too much.

Boy am i glad that i wrote possible there! Served me right.

[Aaron Blain]

 

I'm amused by the technique of artificially stalling the loop. Is this how those speed sliders work, I wonder?

 

I've been playing Bio Menace and it works perfectly. Does Catacombs throttle itself properly? This is actually a bit impressive for that era. I wonder if Romero or Carmack would have anything to say about this. Is anyone familiar with why old RTS games have speed sliders? Is that purely a gameplay choice? I never got into online RTS games because I don't like them with the speed cranked all the way up.

Edited May 27, 2020 by Aaron Blain

[JadingTsunami]

1 hour ago, Aaron Blain said:

Is anyone familiar with why old RTS games have speed sliders? Is that purely a gameplay choice?

 

Yes, this is a gameplay choice. In games I've seen, such sliders modulate the internal simulation speed and are decoupled from the graphical rendering system. Of course, for sprite-based games, the slider will affect the visual rendering as well (since each actor's animation sprites would play more slowly).

 

For those interested, Doom uses the system timer to determine how many tics have elapsed since the last update, and advances its internal logic by that many tics, not to exceed 35 tics/second. This is how Doom did not see speed-up/slow-down issues based on system processing speeds.

[SaladBadger]

to add a little to the given answers to far, Fabien Sanglard's excellent Game Engine Black Book on Doom has some details of the specific system being used, which involves a 140hz timer interrupt (140hz for sound reasons), which when run enough would increment a global ticcount, and the game loop would compare what tick it's last executed.

 

All games of the time had the ability to do these things (and indeed there's even points in the Descent source code where it tries limiting the FPS, that aren't used in normal contexts...), but I guess they didn't because it's a bit annoying to set up.

[Blzut3]

Wolf3D uses the same timer interrupt (also used for servicing sound) to count tics.  Except in the places where it uses vblank.

 

Descent does seem to have some vsync code which is used in the high res modes (most people at this point say it doesn't matter since the cockpit graphics are removed in high res).  I seem to recall 320x100 also being vsync'd but don't see where I saw that off hand and don't have an easy way to confirm at this particular moment.  In any case I've wondered if that code is specific to something in the high res modes or if it could have been an option for 320x200 the whole time that just was disabled since presumably not syncing allows the game to be a little faster.  But from a naive viewpoint it looks like one could flip one bit somewhere in the executable and fix the issue.

[dpJudas]

50 minutes ago, Blzut3 said:

Descent does seem to have some vsync code which is used in the high res modes (most people at this point say it doesn't matter since the cockpit graphics are removed in high res).  I seem to recall 320x100 also being vsync'd but don't see where I saw that off hand and don't have an easy way to confirm at this particular moment.  In any case I've wondered if that code is specific to something in the high res modes or if it could have been an option for 320x200 the whole time that just was disabled since presumably not syncing allows the game to be a little faster.  But from a naive viewpoint it looks like one could flip one bit somewhere in the executable and fix the issue.

The devil is in the detail. With Doom you essentially can't do it wrong in the game code. No matter how you code a tic function it will always run the same on any computer.

 

In variable-rate games like Descent it is very different. The codebase does have a FrameTime variable and 95% of the code does use it correctly. I.e. the Laser shot moves at the same speed on any computer running Descent. It is the last 5% that is making the game break and those weren't noticed during development because as long as the frame rate is in the ballpark it was tested on everything seems reasonably fine.

 

To illustrate why the 5% are so catastrophic, let's take some examples from Descent:

 

1) The ship hover effect. This is essentially a sinus curve effect applied over time. But because it has to be done as a velocity force every tick it gets a little tricky to write it correctly for it to be truly frame rate agnostic. What they did instead was to just not look at FrameTime at all and used an advance speed as a constant.

 

2) The homing missiles. Presumably for performance reasons they only do a hitscan every 8th frame. If the hitscan is successful it compares the angle and if its acceptable it turns the homing missile. Unfortunately the more frames, the less movement difference of the target there will be between each check. The higher the frame rate, the more fast/crazy movement you have to do to make it lose its tracking.

 

3) Keyboard turn input. Coded exactly like Doom does it, but since the tic rate isn't fixed it doesn't work right.

 

Quake 3 and Unreal Tournament is probably also worth mentioning. Two fine examples of games where even if you do remember all the FrameTime calculations, you still can run into problems when time slices get too small. You have to limit the frame rate in those games too because movement and bullet code begins to act a little odd when each individual movement is tiny enough. As a simplified illustration of the problem, imagine you track time by using milliseconds. Sounds good when you have 30-60 fps, but at 1000 fps the delta time value hovers unpleasantly between 0 and 1. If the engine rounds the number down everything freezes, and if it rounds it up everything runs too fast.

[Blzut3]

Yes all of those things I can notice easily on my Tualatin but if I change the resolution they all go away is what I'm saying.  This seems to be because the other resolutions are doing vsync and blocking the entire game engine until vblank.  320x200 explicitly doesn't do this, and I'm not sure if it's limitation of the mode or they just didn't think anyone would want to.