Things about Doom you just found out

Apparently, Slough of Despair is shaped like a hand. Interesting.

You can actually kill monsters if you shoot them.

Revenant100 said:

Just out of curiosity, I downloaded and tested the old ZDoom versions 1.22 and 1.23, and I found that the "jittering while standing still" problem does not occur there. I think this safely narrows the problem down specifically to only ZDoom and its derivatives that was introduced at least somewhere after 1.23.

I'd report this bug on the ZDoom forums, but it seems fairly nebulous in scope.

To illustrate this issue, here's a comparison between ZDoom 1.23 and 2.8.1 while standing from the exact same position and recorded in the same resolution (800x600):
http://i.imgur.com/QJOBcrJ.gif

Since you know where to look for this, can you do us a favor and test a few more versions between 1.23 and now? That's 14 years in between.

Graf Zahl said:

Since you know where to look for this, can you do us a favor and test a few more versions between 1.23 and now?

To more easily identify the problem, I created a simple test map which features a bunch of animated things placed a fair distance from the player:
https://drive.google.com/file/d/0B4X6_GM5D7D_Q1JBWTY1b1A0WjQ/view?usp=sharing

As before, I did my testing in 800x600, but the issue manifests in ZDoom to some degree in all screen resolutions dependent on the player's distance and viewing angle.

Using the past ZDoom builds listed in this directory, the first build I could find where this idle jittering begins to occur is 2.0.21 dated December 10, 2002. However, there is a several month gap between this and the next previous I build could find, 1.23 dated February 5, 2002. I guess that narrows the time span down to somewhere between the 1.X and 2.0 branches.

Comparison image:


Note that the jittering on the impaled human and the twitching hanging corpse things on the right also occurs even in the original executables, so that's not part of the ZDoom issue here. However, the jittering on the small torches, the flaming barrel, and the evil eye are indeed ZDoom-specific.

Vanilla doom (!) has the same problem, but with flats (I know the whole image sifts back and forth, but to the right of the picture you can really see that the floor shifts itself back and forth ingame when the lights blink):



Ray William Johnson used the Doomguy pain sound effect in this video (1:40) :

EDIT : In Ultimate vanilla Doom, if you put the monster spawner in a map, instead of crashing upon startup, all the decoration things disappear (Hanging corpses, Candlabras, etc.)

I just saw a former sergeant getting gibbed by a PE. Never seen that before.

Doompje said:

I just saw a former sergeant getting gibbed by a PE. Never seen that before.

A zombieman, maybe, since it has 20 HP and a Lost Soul can deal up to 24 HP of damage. The zombieman would need to have less than 4 HP left, too. But a sergeant has 30 HP, so that would be impossible.

Maes said:

A zombieman, maybe, since it has 20 HP and a Lost Soul can deal up to 24 HP of damage. The zombieman would need to have less than 4 HP left, too. But a sergeant has 30 HP, so that would be impossible.

How strange, I swear I saw this, even more than once today (d2twid map 27). Is it possible the PE does more damage from up close (melee) then when it just shoots a lost soul?

EDIT: I revisited the spot and I think it might have been a spectre that actually gibbed him.

joe-ilya said:

Vanilla doom (!) has the same problem, but with flats

Yeah, I always found it strange how blinking lights appear to make the floor shift around.. Wonder what that one is all about?

Doomkid said:

Yeah, I always found it strange how blinking lights appear to make the floor shift around.. Wonder what that one is all about?

The Doom engine tries to combine visplanes when it can (sector floors or ceilings with the same texture / height / light level) and it also has some slight rounding-error problems when drawing them based on the starting position. So when a light is blinking it can make a sector either be lumped in the same visplane as the blinking-light sector, or its own visplane, and the flat can change position slightly based on the rounding error.

Doompje said:

Is it possible the PE does more damage from up close (melee) then when it just shoots a lost soul?

PE doesn't do any damage up close - when he tries to spawn a Lost Soul while his target (or something else) is right in front of him up close, the Lost Soul just immediately dies and the up-close thing/monster/player ends up unharmed. This is a base for a common tactic of fighting PEs - as long as you keep hugging him (standing near him, blocking him from spawning Lost Souls), he is completely harmless.

Linguica said:

The Doom engine tries to combine visplanes when it can (sector floors or ceilings with the same texture / height / light level) and it also has some slight rounding-error problems when drawing them based on the starting position. So when a light is blinking it can make a sector either be lumped in the same visplane as the blinking-light sector, or its own visplane, and the flat can change position slightly based on the rounding error.

PrBoom+ and some other ports have code that fixes this, by using more precise calculations.

I discovered that Doom was originally going to have a "Not enough memory" error screen, similar to Wolf3D/SOD.

Revenant100 said:

Stuff

You might find this to be a useful resource.

HavoX said:

I discovered that Doom was originally going to have a "Not enough memory" error screen, similar to Wolf3D/SOD.

https://doomwiki.org/w/images/9/9e/Alpha_ANSI_DOOMERR.gif

Why did they remove it? Probably not just to save file size?

scifista42 said:

Why did they remove it? Probably not just to save file size?

Because it would be mostly irrelevant due to the protected mode, anyway. If you didn't have enough free RAM, that would be it. It was no longer a matter of altering the software configuration with the usual DOS XMS/EMS/whatever clusterfuckery*.

* Well, there were a few TSRs that would prevent Doom from starting if you had just about the minimum amount of RAM (4 MB), most notably SMARTDRV.EXE. But then again practically no protected-mode game included such screens any more, and after 1993-1994 an out-of-memory error would generally indicate a grossly obsolete system.

Revenant100 said:

Using the past ZDoom builds listed in this directory, the first build I could find where this idle jittering begins to occur is 2.0.21 dated December 10, 2002. However, there is a several month gap between this and the next previous I build could find, 1.23 dated February 5, 2002. I guess that narrows the time span down to somewhere between the 1.X and 2.0 branches.

Unfortunately the differences between these two versions are quite significant. That was the time when some major render speed optimizations were done. The actual problem with the torches is that the sprites are different in size, meaning that the projection math is different which, due to roundoff errors results in an off-by-one-pixel effect.

(3 of the short torch sprites are 17 pixels wide, the fourth is 16 pixels wide.)

Maes said:

Because it would be mostly irrelevant due to the protected mode, anyway. If you didn't have enough free RAM, that would be it.

Right. It doesn’t matter if your system has 2GB of RAM... The most important thing as far as DOS games are concerned is how much "conventional" memory your system has.
If you can't get that game to run, chances are, your system had insufficient conventional memory available.

FLAT23 (the silver one) has a circle pattern on it.
Edit: not really Doom-related, but next to every post's date (on DW) there is an octothorpe (#) that is actually a link to the post itself.

bzzrak said:

FLAT23 (the silver one) has a circle pattern on it.

It's for this reason I almost never use this texture!

HavoX said:

Right. It doesn’t matter if your system has 2GB of RAM... The most important thing as far as DOS games are concerned is how much "conventional" memory your system has.
If you can't get that game to run, chances are, your system had insufficient conventional memory available.

About Doom, this is completely and utterly wrong. This was the state of affairs _without_ the protected mode DOS extender. Doom and applications like it can use as much memory as your system has (within the scope of what DOS could comprehend at all). This was the point being explained in the post you replied to.

damerell said:

Doom and applications like it can use as much memory as your system has (within the scope of what DOS could comprehend at all).

My understanding is that vanilla Doom / Doom 2 is hardcoded to use a maximum of 6 MB of RAM, regardless of how much the system has: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/i_system.c#L51

scifista42 said:

PE doesn't do any damage up close - when he tries to spawn a Lost Soul while his target (or something else) is right in front of him up close, the Lost Soul just immediately dies and the up-close thing/monster/player ends up unharmed. This is a base for a common tactic of fighting PEs - as long as you keep hugging him (standing near him, blocking him from spawning Lost Souls), he is completely harmless.

wow, I am playing this game for about 15 years or so and I never found this out until know. (perfectly for this topic at least).

Linguica said:

My understanding is that vanilla Doom / Doom 2 is hardcoded to use a maximum of 6 MB of RAM, regardless of how much the system has: https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/i_system.c#L51

Well it tries to allocate a big chunk of 6 MB according to that code, but it's not clear what happens if that particular allocation fails. They retry with less? I doubt that code is what actually happens in vanilla Doom. In Linux Doom v1.10, maybe.

That being said...vanilla Doom really has a practical limit under DOS, I think something like 8 MB, confirmed here:

http://www.flaterco.com/kb/DOOM/VanillaDOOM.html

And also I personally noticed that even in VMs, DOSBOX or "super retro" DOS builds with much more RAM than that, Doom reports something like 0x800000 (about 8 MB decimal) for its Zone memory, never more.

Of course, whether 6 or 8 MB, the protected mode malloc-accessible heap will start past the 1 MB mark, so you'd need more than exactly 6 or 8 MB of RAM installed if you really wanted to max Doom out, and even more if you wanted to run SMARTDRV.

Good ole Linux code. As usual, Heretic to the rescue: https://github.com/OpenSourcedGames/Heretic/blob/b6d928b3c8d424028a8f2d693d2066201320cd01/Heretic%20Source/I_IBM.C#L1880

I thought DooM was supposed to take advantage of 32 MB.

The Heretic code I linked is presumably very similar to, if not identical, to the Doom code, and it appears to do the following:

* get the info about the local environment or whatever and find the amount of memory available to DPMI
* subtract 64k from that amount
* if the amount is bigger than 8 megs or so, make it 8 megs
* try and allocate that amount
* if for some reason it fails, subtract another 64k and try again, etc

if this ends up being less than about 1.5 MB of RAM, Heretic (and probably Doom?) will complain about it and quit.

It kind of makes me wonder what would happen if you just went in with a hex editor / decompiler, found that value, and raised it 🤔

A better question would be who and why decided that that value should be 6 MB? Why not more? I can only think of a bug with the DPMI extender itself, or broader compatibility issues.

E.g. were all systems at the time capable of really using 8 MB of physical RAM? Not just what the CPU can theoretically address (which should be 4 GB for an i386...and we saw how well that worked when 4 GB became a reality, 10 years later *rolleyes*), but effective support. E.g. 386 SXs couldn't go beyond 16 MB anyway, I think, but that still doesn't explain why an oddball number like 6.

Keep in mind, that in order to have 6 MB of continuous DPMI heap, you'd have to have 8 MB of physical RAM installed anyway: anything below 1 MB was dead weight due to conventional DOS memory, TSRs, interrupts and and BIOS shadowing, and no legal combination of SIMMs or DIMMs could give you 7 MB.

Linguica said:

My understanding is that vanilla Doom / Doom 2 is hardcoded to use a maximum of 6 MB of RAM,

True (modulo subsequent discussion of the details), and I didn't know that, but that's not quite what I meant - Doom _could_ use 32MB if you had it, running under the extender.

damerell said:

True (modulo subsequent discussion of the details), and I didn't know that, but that's not quite what I meant - Doom _could_ use 32MB if you had it, running under the extender.

You mean it could have used 32mb, if it was programmed differently?

OK ... I guess :P