Things about Doom you just found out

Linguica said:

A shotgun / chaingun dropped by a dead enemy will only give you half as much ammo with it as one placed in the level. How did I never notice that?!?

There's an even more interesting gimmick that takes effect when you use DEHACKED to change the pickups. If DEHACKED is used, pickup types are defined simply by the displayed sprite. So if you DEHACKED-change the clip pickup to look like a chaingun, it will give you the chaingun. But, clip is also being dropped by the Zombieman and SSNazi. And of course, it'll still look like a chaingun and give you the chaingun when dropped. AND here is the interesting part: It will give you the same amount of ammo as a chaingun standardly placed in the level - not a halved amount. Vice versa, if you change a shotgun or chaingun to an ammo pickup, and let the shotgunguy or chaingunguy drop it, the dropped pickup will give you as much ammo as the same pickup again, not halved, as it would normally happen. But if you just change an ammo pickup to a different ammo pickup, or a weapon pickup to a different weapon pickup, then the dropped version will give you halved ammo as usual.

If the player is out of shells and is using the fist or pistol, picking up shells will cause the player to switch to the shotgun.

If the player is out of cells and is using the fist or pistol, picking up cells will cause the player to switch to the plasma gun.

If the player is out of rockets and is using the fist but NOT the pistol, picking up rockets will cause the player to switch to the rocket launcher. (??)

^Weapon priority order. Rocket launcher's priority is between the pistol and the fist. I've seen an exact list how the priority of Doom's weapons goes, but I can't find the list right now.

Not exactly. It's explicitly in the code for some reason (edited here):

case am_shell:
	if (player->readyweapon == wp_fist || player->readyweapon == wp_pistol)
		if (player->weaponowned[wp_shotgun])
			player->pendingweapon = wp_shotgun;
	
case am_cell:
	if (player->readyweapon == wp_fist || player->readyweapon == wp_pistol)
		if (player->weaponowned[wp_plasma])
			player->pendingweapon = wp_plasma;
	
case am_misl:
	if (player->readyweapon == wp_fist)
		if (player->weaponowned[wp_missile])
			player->pendingweapon = wp_missile;

Linguica said:

Not exactly. It's explicitly in the code for some reason (edited here):

Oh. But the priority list corresponds with the theory. I've just found the list, here it is:

plasma gun > super shotgun > chaingun > shotgun > pistol > chainsaw > rocket launcher > BFG9000 > fist

I suppose, but that would suggest that if the player is using the chainsaw and picks up shells or cells, it should switch to the shotgun / plasma rifle, since those are considered higher priority than the chainsaw as well.

I'm sure it was more of an ad hoc decision and not all part of an intricate plan. It still seems odd.

Linguica, this might sound a bit silly, but I just want to say that I really love those animated gifs you post when going into technical details about the Doom engine. They're really well done and make the subject matter much easier to understand. Thanks for posting them.

The bottom of the Doom2 city sky is water with reflections of the buildings and fire.

Krazov said:

I just found out that if you press A in Doom Builder 2, it will align texture horizontally. And I was thinking that I would have to do that all by myself, linedef by linedef.

No sweat, I've found out after a good year - like 12.5-13 months - of mapping with little breaks that 'J' makes two sectors one, even if they're separated by nature. Halfening your maps' sector definitions, thus their size has never been more of a relief to me.

My beforehead action of joining sectors was:
1. interconnecting them with a thin path;
2. delete adjactency lines -> included sectors become pitch black ("broken");
3. creating new sector within one of the origins (not the path, because it just messes up with it even more);
4. eliminate path; sometimes I had luck and could draw it in one piece, meaning that I didn't have to redo the one sector it was crossing.

What a waste of time it was. Of course, discovering Autoalign itself was another issue to mention, but it had its charms as well.

BlueFeena said:

Linguica, this might sound a bit silly, but I just want to say that I really love those animated gifs you post when going into technical details about the Doom engine. They're really well done and make the subject matter much easier to understand. Thanks for posting them.

Me too! I rarely get around to making gifs but they are really awesome and convenient.

I had always assumed that the partial invisibility code in Doom had some element of randomness to it. Nope! It just loops over a 50-element array over and over! No randomness at all!

Here's my sweet custom weapon sprite, which just happens to be a 50-pixel square:



Now let me just turn on partial invisibility (and invulnerability to boot, so it's easier to see):



Well that kind of destroys the effect doesn't it. And it never moves:

Also it's kind of sad that id had the notion of adding special effects in the framebuffer - like basically every modern game nowadays does extensively - but (to my knowledge) only ever used it for a barely-noticeable pixel warp in the partial invisibility effect.

This pixel warp is more noticeable in 320x200. A bit sad that no source port (that I know of) scales fuzz effect in high resolutions.

It's one of those situations when leaving the original algorithm untouched makes the picture less authentic in high res.

Linguica, stop being so awesome already. I don't know how much more I can take.

Da Werecat said:

This pixel warp is more noticeable in 320x200. A bit sad that no source port (that I know of) scales fuzz effect in high resolutions.

KBDoom does (but, it's not yet released publically). It's actually quite difficult to do "properly" and efficiently. KBDoom fakes it, but I like the results. There's also an option to fix the non-randomness of the effect, so you never see patterns in the effect.

One day, I'll release the source and let everyone pick it apart :)

Haha, that's awesome Ling, I never realized that either.

Da Werecat said:

This pixel warp is more noticeable in 320x200. A bit sad that no source port (that I know of) scales fuzz effect in high resolutions.

It's not the original fuzz effect, but you can use a pixelated version of the fuzz shader in GZDoom. It looks a lot closer to the software fuzz effect at 320x200, and I like it, but it's really not any good at obscuring sprites when you're playing at high resolution. You need that low res chunky background for low res chunky fuzz to do its job.

Also from the code, I think it's extremely likely that they intended to do an warping effect like the Predator had (copying something from an 80s action movie, shocking right), and Carmack starting hashing it out, went "eh, good enough" and then left it unfinished.

The whole invisibility effect is done by going down each column of the sprite one pixel at a time, copying the pixel above or below the current pixel, darkening it a little, and pasting it in the current place. Every dark area in a partially invisible sprite is because there's a run where the engine keeps copying from the pixel above it and darkening it more, so it quickly looks almost black. (You can see there are two major runs like this in the vanilla code if you look at the picture above, and a few minor ones.) This means it's very difficult to tell the engine is even moving around existing pixels, because when they're darkened, they don't look the same, so you don't even notice.

If you edit the source so that it doesn't darken the pixels as it copies them, it's more apparent what they were probably originally thinking about.

I found out this existed

I was bored and thinking about part of the original press release Tom Hall wrote for Doom:

Light Diminishing/Light Sourcing

Another touch adding realism is light diminishing. With distance, your surroundings become enshrouded in darkness. [...] [This] feature[] will make the game frighteningly real.

And I was thinking, well that's all well and good, but "light diminishing" is hardly a realistic phenomenon. Lighting doesn't actually get dimmer the further away you are from it, that's silly. There's no "black fog" in real life. So I wondered what it would look like if I disabled it:





Turns out when things don't fade into darkness in the distance the game looks a lot worse, who knew??

Linguica said:

If you edit the source so that it doesn't darken the pixels as it copies them, it's more apparent what they were probably originally thinking about.

That actually looks really neat. I should try and see how that looks in a higher resolution.
Edit: So resolution can make this effect really subtle:



I wonder if messing with the fuzztables could produce a more visible output.

Linguica said:

Turns out when things don't fade into darkness in the distance the game looks a lot worse, who knew??

3D hardware accelerated ports and games in general (e.g. Quake) tend to look like that. I rationalize the light diminishing effect as the player holding a light source inside a dark passage. Or if the sector is really dark, then only one meter around is lit up (especially with the possibly fixed PrBoom bug), which simulates you touching the walls.

Very interesting stuff, as always, Linguica.

Today I learned what was the meaning of Episode 1’s ending:

John Romero said:
The story is that the game ends just before Doomguy completely opens up on the demons and destroys them all as usual, then continues his journey in Hell.

Bye, bye, Buddy Dacote theory. I mean, we have Death of the Author but still—some ambiguity I liked that much is gone.

Linguica said:

If you edit the source so that it doesn't darken the pixels as it copies them, it's more apparent what they were probably originally thinking about.

The version without the pixel darkening looks fucking awesome, I'd love to see that as an optional version of the effect in a sourceport or two.

I've found out that when using "Linedef Action 271: Transfer Sky Texture to Tagged Sectors", only the linedef's upper texture defines the sky texture for both floor and ceiling sky, while the linedef's lower texture doesn't matter at all, as it seems.

Linguica said:

Turns out when things don't fade into darkness in the distance the game looks a lot worse, who knew??

I think OpenGL rendered source ports are like that, which is why I prefer software rendering. I have t played around with it, but are there hardware rendered source ports that simulate dooms lighting with a black fog, that increases in density on darker sectors?

40oz said:

I have t played around with it, but are there hardware rendered source ports that simulate dooms lighting with a black fog, that increases in density on darker sectors?

Yes. GZDoom even has a special shader lighting mode that was added to perfectly emulate software lighting (minus chunkiness). GLBoom+ also features it.

Linguica said:

"light diminishing" is hardly a realistic phenomenon. Lighting doesn't actually get dimmer the further away you are from it, that's silly.

Simply amazing. That means you could disconnect all streetlights in Manhattan and hoist just one to the top of the Empire State building, The streets at night would be just as bright as with thousands of the current streetlights, but think of all the electricity this would save.

There just might be a Nobel Prize in this for you, Linguica.

You're both sorta wrong. Light diffusion is definitely a thing, but we're not talking extreme distances like from the top of the Empire State building to, I dunno, northern Manhattan. We're talking maybe 100-200 feet. The way light fades out at a distance in Doom is simply not realistic.

Doom? Realistic? Pwhahaha... Oh Doomworld