Things about Doom you just found out

[fai1025]

Fun Fact all the weapon sprite in Doom (except pistol, fist, chainsaw) are not centered

i just find this out while editing the sprite

[Kyka]

8 hours ago, baja blast rd. said:

 

 

Wow so you can pick up the megasphere but not the megarmor? wow. I really have learned something today. Good observation.

[Gez]

9 hours ago, Kyka said:

I discovered today just how terrible GZDoom is at handling lots of midtextures compared to what it was ten years ago. I base this on a particular region in a project I am working on, and that area used to run fine. (I haven't worked on this project in ten years, came back to it recently.) And discovered that this area, which  used to run fine, (ON the now defunct ZDoom) now makes my computer chug down to around 1 fps. Weird. Not a criticism even, I am just curious as to why this may be. And if it is fixable.

Are you still on the same computer from 10 years ago?

 

GZDoom has had most of its rendering code rewritten but the focus is on optimizing performances on modern hardware. You'll get best perfs if you have a Vulkan-capable GPU and use the Vulkan backend.

 

If you've got an old machine, then you run into the problem that generally most of the optimizations that speed up stuff on modern hardware will slow things down on older computers, and vice-versa. You can try the OpenGLES backend instead to see if it'll make things better. Keep in mind that the drawback of the GLES backend is that it only supports a subset of GZDoom's fancy graphical features; which makes sense since GLES is a trimmed-down, lightweight version of OpenGL for embedded systems (like an old smartphone) so you can't ask too much from it.

 

9 hours ago, Firedust said:

Here's something I'm curious about. We all know that green and blue armor work differently. So, say, I pick up 1 green armor and, after that, 100 armor bonuses. Will I be able to pick up a megaarmor now? Or will I have to take damage first?

You can only pick up an armor if your armor percent is lower. That means you can pick up a green armor if your blue armor has been reduced to 99, but you can't pick up a blue armor if your green armor has been boosted to 200. This is important because blue armor absorbs a greater fraction of damage than green armor, so a 200% green armor is worse than a blue armor, but you can't upgrade because you're already at 200.

 

Here's some vanilla code. First, the function that gives armor.

//
// P_GiveArmor
// Returns false if the armor is worse
// than the current armor.
//
boolean
P_GiveArmor
( player_t*	player,
  int		armortype )
{
    int		hits;
	
    hits = armortype*100;
    if (player->armorpoints >= hits)
	return false;	// don't pick up
		
    player->armortype = armortype;
    player->armorpoints = hits;
	
    return true;
}

So you can see how it works internally. You try to give an armortype (that, spoiler alert, will be either 1 or 2), it multiplies that armortype by 100 to get its hit points, and if your current armorpoints are greater or equal to that value, you can't pick up the armor. If you can pick up the armor, it updates your armorpoints and your armortype to that of the new armor. Note how the check is only done on the armorpoints, and not on the armortype.

 

Second is the function that picks up items. It's very long since there's code for every single pickup, so I'll trim it down to just the bits about picking up green armor, blue armor, and megasphere. Not included is the code at the very beginning that checks that the pickup is valid, and at the very end that, if the function didn't hit a return in the meantime, removes the pickup from the world and updates the player's items count if relevant.

    // Identify by sprite.
    switch (special->sprite)
    {
	// armor
      case SPR_ARM1:
	if (!P_GiveArmor (player, 1))
	    return;
	player->message = GOTARMOR;
	break;
		
      case SPR_ARM2:
	if (!P_GiveArmor (player, 2))
	    return;
	player->message = GOTMEGA;
	break;

...

      case SPR_MEGA:
	if (gamemode != commercial)
	    return;
	player->health = 200;
	player->mo->health = player->health;
	P_GiveArmor (player,2);
	player->message = GOTMSPHERE;
	sound = sfx_getpow;
	break;

So the armor pickups check if P_GiveArmor is successful. If it fails, the function ends there (return); while if successful it displays a message telling you you picked the armor up. The megasphere pickup (which only works in Doom II, if you put a megasphere in Doom 1 it will be inert) will always be picked up and always set your health to 200, but it gives a blue armor without checking if it worked or not. But it does that by using the same function as for regular armors. So if you have a green armor boosted to 200% and you pick up a megasphere... You'll still have a green armor. Not a blue armor.

[Kyka]

30 minutes ago, Gez said:

Are you still on the same computer from 10 years ago?

 

GZDoom has had most of its rendering code rewritten but the focus is on optimizing performances on modern hardware. You'll get best perfs if you have a Vulkan-capable GPU and use the Vulkan backend.

 

If you've got an old machine, then you run into the problem that generally most of the optimizations that speed up stuff on modern hardware will slow things down on older computers, and vice-versa. You can try the OpenGLES backend instead to see if it'll make things better. Keep in mind that the drawback of the GLES backend is that it only supports a subset of GZDoom's fancy graphical features; which makes sense since GLES is a trimmed-down, lightweight version of OpenGL for embedded systems (like an old smartphone) so you can't ask too much from it.

 

(Also really interesting stuff about armor pickups and megaspheres, edited out to save some scrolling.)

 

No my PC now is a decent midrange machine, able to run modern games with high, though not ultra settings, so probably an order of magnitude better than what I had ten years ago.

 

To give some context, here is the offending area:

 

Spoiler

 

There certainly is a lot of midtextures, but it used to run fine on a much lower spec PC, and it chugs now on a far superior one. Is there anything that can be done if/when I release this, to make it not die on the average system? or is it simply a case of removing many of the offending midtextures?

 

Thank you for the reply/explanation btw.

[Gez]

You can try the console commands 'stat rendertimes' and 'stat renderstats'; it'll give you a bunch of info about how much time is spent rendering what.

 

That said, do check various rendering mode. If it worked fine in ZDoom, for example, then check in software mode. For hardware mode, you can check the various backends (GLES, GL, VK) and you can also check the various post-processing options, see if you can turn off some.

[Kyka]

As ever Gez. thanks for the advice. If I find an option that works, is it possible to 'force' any of these settings within a project, so that if another player happens to be playing this mapset, the mapset will default to the appropriate settings?

[Dragonfly]

3 minutes ago, Kyka said:

is it possible to 'force' any of these settings within a project

 

Renderer selection cannot be forced, no, but you could put a big fat "READ ME FIRST!!!!!!!!!1.txt" file in the zip containing the project so people who typically skip reading anything and just boot it at least have a chance of seeing the recommended settings. 

[Kyka]

1 minute ago, Dragonfly said:

 

Renderer selection cannot be forced, no, but you could put a big fat "READ ME FIRST!!!!!!!!!1.txt" file in the zip containing the project so people who typically skip reading anything and just boot it at least have a chance of seeing the recommended settings. 

 

Damn good advice. Thank you. :)

[Osmosis Bones]

when using the zdoom version of TEXTUREx you can make stuff with not just the textures, but all the sprites, flats, even bits and pieces of the UI!

[Devalaous]

Holy shit Kyka, what on earth is that you've unleashed!?

 

On topic: Today I learned Hell Revealed was apparantly made when the authors were young teenagers. That....explains a LOT about the weird memey graphics and the more serious 'Episode One' release going from 'actual attempt at story' to 'fuck story get in there and killlllllll', very typical kid thing to lose focus like that.

[Herr Dethnout]

Probably well know by everybody, but I just found that the Barons only need 5 rocket launcher shots to die.

Heh

[Maximum Matt]

And that Hell Knights can die from just 2 rockets (if you're real lucky), and that demons can survive a rocket (if you're real UN-lucky)

[peach freak]

7 hours ago, Herr Dethnout said:

Probably well know by everybody, but I just found that the Barons only need 5 rocket launcher shots to die.

Heh

 

I believe you could even drop one in 4 Rockets if all four Rockets dealt near-maximum damage (averaging 250HP per hit).

[Faceman2000]

3 hours ago, Maximum Matt said:

And that Hell Knights can die from just 2 rockets (if you're real lucky), and that demons can survive a rocket (if you're real UN-lucky)

I saw someone mention that in here and I was blown away and confused as to how I’d never seen it happen - and then I saw it happen the very next day. I’m sure it’s happened plenty of times before and I had just assumed the Hell Knight was already damaged.

[Kyka]

In near 30 years of playing Doom, I have never seen a blockmap crash. And over the last month I have seen 3. They are impressive when they happen. 

 

HL3 confirmed.

[Rykzeon]

Hitscan attacks hit invisible barries in large_open_areas
Is this still relevant?

[Gez]

17 hours ago, Herr Dethnout said:

Probably well know by everybody, but I just found that the Barons only need 5 rocket launcher shots to die.

With some contrivance, you could kill a baron with a single rocket. It requires placing other monsters around it and exploiting a blockmap glitch so that it gets blast damage inflicted repeatedly. See second video for the baron kill.

 

[Sonikkumania]

Looking at decino's thumbnail, I just realized that original Doomguy sprite weapon looks really similar to FAMAS, the French assault rifle.

[RastaManGames]

I never seen this particular window on "Abandoned Mines" before...

Spoiler

 

[ＤΞＬＴΛ]

1 minute ago, RastaManGames said:

I never seen this particular window on "Abandoned Mines" before...

  Hide contents

 

I have never noticed that before...

[Kyka]

20 minutes ago, RastaManGames said:

I never seen this particular window on "Abandoned Mines" before...

  Hide contents

 

 

Wait what? Yeah I have never seen that either. :)

[Stupid Bunny]

If you ever feel like your existence is pointless just think of the chaingunner posted behind a window nobody ever saw

[RoastDoom]

I only found out today that in Tricks and Traps, two teleporters to the exit lower in the caco room if you back off just after you trigger the falling platforms. 

[Solmyr]

Thanks to Voxel Doom i found out that properly 3D rendered Pinkies look much more goofy when they attack, their heads looks so oversized it obscures the rest of it's body and takes 40% of the screen at melee range. It's hilariously cursed.

 

Cacodemon corpses' optical nerve/muscles are just Baron's/Hell Knight's guts.

 

The classic UAC logo has an airplane shape in the empty space in-between the overlapping ovals.

[Faceman2000]

1 hour ago, Solmyr said:

Thanks to Voxel Doom i found out that properly 3D rendered Pinkies look much more goofy when they attack, their heads looks so oversized it obscures the rest of it's body and takes 40% of the screen at melee range. It's hilariously cursed.

I love everything about Voxel Doom except the Pinkies. They look super goofy when they attack and their corpse looks really awkward to from all angles except the front. I know this is more of an issue with the original art than anything but the rest of the mod feels so seamless but the Pinkies really stick out to me.

[Solmyr]

1 hour ago, Faceman2000 said:

I love everything about Voxel Doom except the Pinkies. They look super goofy when they attack and their corpse looks really awkward to from all angles except the front. I know this is more of an issue with the original art than anything but the rest of the mod feels so seamless but the Pinkies really stick out to me.

Cheello did an outstanding work with his Voxel mod, but the voxelized Pinkies are a strong contender about how 2D sprites are sometimes more appealing than even Voxels which themselves are thousands of times more appealing than old 3D models in Doom.  

[Sectorslayer]

There are 3 sound levels in Doom. 2 being the loudest and 0 representing silence. When sound travels across a Linedef that has the sound block flag set, the volume is reduced by 1. Thus sound traveling across two or more blocking Linedefs will not be heard by monsters. That's why two sound blocking Linedefs are needed to stop sound propagation.

[Kyka]

8 hours ago, sectrslayr said:

There are 3 sound levels in Doom. 2 being the loudest and 0 representing silence. When sound travels across a Linedef that has the sound block flag set, the volume is reduced by 1. Thus sound traveling across two or more blocking Linedefs will not be heard by monsters. That's why two sound blocking Linedefs are needed to stop sound propagation.

 

Does the sound being reduced to 1 and then to 0 do anything in terms of volume? or is it purely to set flags for when sound crosses the sound block lines?

[Gez]

Technically, there's just two levels: regular and attenuated. There's no need for a silence volume level, since the absence of sound works better than the presence of a silent sound.

 

Here's the line flag:

// Sound rendering: don't let sound cross two of these.
#define ML_SOUNDBLOCK		64

Calling it "sound rendering" is, IMO, a misnomer since we're not talking about actual audio here, but an abstraction of sound cues for the AI.

 

And now, the actual sound functions:

//
// Called by P_NoiseAlert.
// Recursively traverse adjacent sectors,
// sound blocking lines cut off traversal.
//

mobj_t*		soundtarget;

void
P_RecursiveSound
( sector_t*	sec,
  int		soundblocks )
{
    int		i;
    line_t*	check;
    sector_t*	other;
	
    // wake up all monsters in this sector
    if (sec->validcount == validcount
	&& sec->soundtraversed <= soundblocks+1)
    {
	return;		// already flooded
    }
    
    sec->validcount = validcount;
    sec->soundtraversed = soundblocks+1;
    sec->soundtarget = soundtarget;
	
    for (i=0 ;i<sec->linecount ; i++)
    {
	check = sec->lines[i];
	if (! (check->flags & ML_TWOSIDED) )
	    continue;
	
	P_LineOpening (check);

	if (openrange <= 0)
	    continue;	// closed door
	
	if ( sides[ check->sidenum[0] ].sector == sec)
	    other = sides[ check->sidenum[1] ] .sector;
	else
	    other = sides[ check->sidenum[0] ].sector;
	
	if (check->flags & ML_SOUNDBLOCK)
	{
	    if (!soundblocks)
		P_RecursiveSound (other, 1);
	}
	else
	    P_RecursiveSound (other, soundblocks);
    }
}



//
// P_NoiseAlert
// If a monster yells at a player,
// it will alert other monsters to the player.
//
void
P_NoiseAlert
( mobj_t*	target,
  mobj_t*	emmiter )
{
    soundtarget = target;
    validcount++;
    P_RecursiveSound (emmiter->subsector->sector, 0);
}

So how does this work. Well, first, when sound is emitted by a player weapon (ignore the comment about monster yells, such thing is not actually implemented), it calls P_RecursiveSound on the sector of the emitter (not "emmiter", sheesh, 1993 id Software had terrible spelling) and a "soundblocks" value of 0. P_RecursiveSound then marks the sector and goes through each line of that sector to find the sectors on the other side of the line. There we this check, which is where the magic happens:

	if (check->flags & ML_SOUNDBLOCK)
	{
	    if (!soundblocks)
		P_RecursiveSound (other, 1);
	}
	else
	    P_RecursiveSound (other, soundblocks);
    }

"If the line blocks the sound, then if we haven't been blocked already go recurse through the other sector while noting we have been blocked (second parameter is 1 instead of 0). Otherwise (if the line is not sound-blocking) then go recurse through the other sector, keeping the current level of blockedness (second parameter is soundblocks).

 

And so we can see that there's no real volume level, there's a soundblocks counter. Therefore, 0 is the loudest (sound wasn't blocked), 1 is attenuated (sound has been blocked), and 2 and above simply do not exist.

[Sectorslayer]

Thanks for digging through the code, @Gez! It looks like the description I found was accurate but wrong after all.

Why did ID implement it that way? Why not just stop sound immediately? Carmack wanted to go fast. Why the extra loops here? I guess Doomworld collectively knows this somehow...