Zdoom not so true to its source...

[Hellbent]

So I keep discovering ways in which Zdoom does not behave like original doom, much to my dismay. I've been using zdoom for almost forever and don't want to adopt a new source port. But if there is no way to get zdoom to behave like doom.exe then perhaps I will need to.

1. It's recently come to my attention that zdoom has some kind of "blockmap" "fix" that makes the spiderdemon easier to kill with one bfg blast. :( Is there anyway to get zdoom to not umm.. do that?

2. Zdoom apparently makes killing monsters, such as spiderdemon, easier in other ways. Is there any way to get zdoom to have behavior like original doom? I'm not interested in retaining limits of original doom.exe such as vis_plane overflow; I'm interested in behavior fidelity. Ie, I want rockets and their damage to behave like original doom. I want monsters to be of the same difficulty in all scenarios--to behave just like doom.exe monsters in all situations. I want the physics to be the same--I don't want a source port that makes anything easier than original Doom as far as behavior and physics go--if fidelity isn't possible in a high res source port, then I'd prefer quirks to make Doom HARDER, not easier. I do want things like free look, cross hair, etc as toggle-able options. If it's not possible to get Zdoom to be true to its roots, can anyone recommend a port that has wide screen high resolution support (~1600x1050) and will behave like normal doom without making it easier?

Are there source ports that allow you the option to adjust various settings to allow a true Doom experience (as described above) while giving the options of more "functionality"? (such as no infinitely tall objects, freelook, crosshair, autoaim, jumping etc--I like these options as options).

Thanks.

[Gez]

Another example of the blockmap glitch in action:
http://www.classicdoom.com/odddemos.htm#manormis

Basically, the blockmap glitch results in hitscans passing through enemies instead of hitting them. Since most of the BFG's damage is dealt through its hitscan tracers, it's a weapon which is especially affected by the fix.

But if you think all the fixed bugs work in the player's advantage, you're mistaken.
http://www.classicdoom.com/odddemos.htm#02noview
http://www.classicdoom.com/odddemos.htm#nontoxic
http://www.classicdoom.com/odddemos.htm#blindav
http://www.classicdoom.com/odddemos.htm#impmiss

[Dragonsbrethren]

Hellbent said:

Are there source ports that allow you the option to adjust various settings to allow a true Doom experience (as described above) while giving the options of more "functionality"? (such as no infinitely tall objects, freelook, crosshair, autoaim, jumping etc--I like these options as options).

Thanks.

Eternity. No clue about widescreen resolutions, but it has everything else you've asked for.

[Vermil]

The last stable version of Doomsday, 1.8.6*, is actually pretty faithful to the original Doom engines behaviour if you don't mind GL rendering.

It maintains things like the blockmap glitch, Lost Soul limit etc and has no compatibility list like ZDoom because it never changed them in the first place :p

Though, naturally, the original Dos engine is the only thing that will 100% imitate the original Dos engine :p

*I'm intentionally avoiding the 1.9 Beta's because, well, they are beta's.

[Graf Zahl]

Hellbent said:

Are there source ports that allow you the option to adjust various settings to allow a true Doom experience (as described above) while giving the options of more "functionality"? (such as no infinitely tall objects, freelook, crosshair, autoaim, jumping etc--I like these options as options).

Thanks.

No, there is no option. This is not something that can be switched on or off. Either you do the blockmap linking in the broken way Doom originally did and accept that some things just won't work with it (like the invisible bridges, for example - which were the main reason for changing it) or you do it right and live with the changes this implies.

I only can repeat myself: If you want all those quirks to be preserved, use another engine. In this case ZDoom is not right for you.

[Hellbent]

Graf Zahl said:

No, there is no option. This is not something that can be switched on or off. Either you do the blockmap linking in the broken way Doom originally did and accept that some things just won't work with it (like the invisible bridges, for example - which were the main reason for changing it) or you do it right and live with the changes this implies.

I only can repeat myself: If you want all those quirks to be preserved, use another engine. In this case ZDoom is not right for you.

Alright, fair enough. Don't get me wrong, I love Zdoom. I think it is excellently designed in all respects. It is the only port I've used consistently for like ten years now. Maybe I should find or make a mod that makes the BFG 25% less powerful. Because the BFG just seems a bit too powerful with that bug fix.

[Enjay]

The flipside to it is, of course, that I was trying to attack a spiderdemon the other day on a non-Zdoom based port and I could hardly hit the bloody thing because the fix has not been applied. At least, I think it is to do with the same bug. Anyway, it just seemed stupid that I could stand right up against this huge enemy and keep missing it. Of course, that is another example of Zdoom making the game easier but, IMO, it is doing it in a good way.

Anyway, why does the final boss of Doom have 1000 less hit points than the mid-game boss? Give it 5000 hit points and a blockmap fix and the spider would still be tough enough. :P

[Graf Zahl]

... and make it smaller so that its physical size resembles the sprite.

[Hellbent]

Yes, I agree with both of you guys. It should definitely have more hit points. I think 5000 is good.

[printz]

More like 10000, which I think is the telefrag limit.

[Super Jamie]

What would happen if a monster had >10001 hitpoints and you telefragged it?

[Gez]

If the monster has enough hit points to survive a telefrag, you get stuck inside it. You can replicate the same effect by noclipping inside a monster, then toggling noclip off.

That said, the telefrag limit is 1 000 000.

[EarthQuake]

Hellbent: Try ZDaemon. It's not perfect, but as far as a ZDoom-engine gets, it's the closest thing to Vanilla Doom. There are certain multiplayer-oriented things about it that differ, but other than that, it makes a great single player port.

[RjY]

Graf Zahl said:

No, there is no option. This is not something that can be switched on or off. Either you do the blockmap linking in the broken way Doom originally did and accept that some things just won't work with it (like the invisible bridges, for example - which were the main reason for changing it) or you do it right and live with the changes this implies.

Given that P_BlockThingsIterator calls a function for every mobj linked into a given blockmap square (bx,by): how about putting in a check which, in compatibility mode, ignores the mobj if its centre point (mobj->x, mobj->y) isn't in the square (bx,by)?

[Graf Zahl]

That won't work. The fix required other changes to the way the blockmap iterators are being set up.

[DaniJ]

Please do elaborate on what those changes were.

[printz]

While this thread lives, I'd also add that in vanilla Hexen clerics and mages can't damage-thrust others with their melee attacks, unlike in ZDoom.

EDIT: Good thing there's Doomsday.

[Graf Zahl]

DaniJ said:

Please do elaborate on what those changes were.

Tha major change was to link all actors into all blocks they touch. As a result the global constant MAXRADIUS was set to 0. The only reason this constant even existed was to work around the design flaw so with the fixed algorithm it was no longer needed.

[DaniJ]

Anything else? I'm trying to formulate a solution that will both fix the problem and emulate vanilla behavior.

[Gez]

printz said:

While this thread lives, I'd also add that in vanilla Hexen clerics and mages can't damage-thrust others with their melee attacks, unlike in ZDoom.

Again with that? I've seen nothing in Hexen's source code to support this allegation.

The mage's frost shard (only mage weapon with a melee attack) calls P_DamageMobj. P_DamageMobj checks for the MF2_NODMGTHRUST flag. The only actors that have that are MT_POISONCLOUD, MT_MWANDPUFF, MT_MWANDSMOKE and MT_MWAND_MISSILE. One of these actors (MT_MWANDPUFF) doesn't exist in ZDoom at all since it's not actually used by anything in Hexen. The three others have the flag. So the vanilla mage melee attack can damage thrust. It can and it does.

As for the mace of contrition and the serpent staff, their code is far too spaghetti like for me to bother spending more time trying to follow it just for the sake of an argument (they call P_LineAttack which sets up some semi-global variables then call a bunch of functions which don't seem to do anything with said variables and it's a mystery when they get down to actually inflict any damage, let alone thrust stuff or not). I can concede you they don't thrust if you want. The mage attack does.

[Gez]

Database error-induced accidental double-post, sorry.

Hey, Dani, what about that Shadowcaster tool? :P

[printz]

Gez said:

Again with that? I've seen nothing in Hexen's source code to support this allegation.

Forget about checking in the source. It's much easier to just play it in vanilla or jHexen, MAP01. Unlike other changes, this one matters in game, because without ability to thrust, you may well be screwed and doomed when surrounded. I can see the sense in non-fighters being unable to push: the fighter has to be specifically strong in this game.

Probably my own bad luck that the code could be so hacky or spaghetti-like, as you're describing it. It could be a gross Hexen hack that makes such attacks unable to push, yet odd because Hexen also has a mobj flag for it. But I think it's nothing that can't be fixed with DECORATE.

In case you're unmovable on this argument, I hope I can still solve it by making my own Hexen ZDoom map wads with the fix in them. Are player classes replaceable?

[Graf Zahl]

Gez said:

As for the mace of contrition and the serpent staff, their code is far too spaghetti like for me to bother spending more time trying to follow it just for the sake of an argument (they call P_LineAttack which sets up some semi-global variables then call a bunch of functions which don't seem to do anything with said variables and it's a mystery when they get down to actually inflict any damage, let alone thrust stuff or not). I can concede you they don't thrust if you want. The mage attack does.

I don't see the problem, except that you obviously didn't get it right. :P

What these functions do is:

- Call P_AimLineAttack to check if something attackable is in reach
- if something is found, call P_LineAttack to actually perform an attack.
- repeat the same procedure for several different shooting angles.


True, the global variables are an utter mess - which is why ZDoom doesn't have them anymore.

[Gez]

printz said:

Forget about checking in the source.

That's not how you're ever going to fix the issue in a faithful way.

Graf Zahl said:

- if something is found, call P_LineAttack to actually perform an attack.

P_LineAttack:

void P_LineAttack (mobj_t *t1, angle_t angle, fixed_t distance, fixed_t slope, int damage)
{
	fixed_t         x2, y2;

	angle >>= ANGLETOFINESHIFT;
	shootthing = t1;
	la_damage = damage;
	x2 = t1->x + (distance>>FRACBITS)*finecosine[angle];
	y2 = t1->y + (distance>>FRACBITS)*finesine[angle];
	shootz = t1->z + (t1->height>>1) + 8*FRACUNIT;
	shootz -= t1->floorclip;
	attackrange = distance;
	aimslope = slope;

	if(P_PathTraverse(t1->x, t1->y, x2, y2, PT_ADDLINES|PT_ADDTHINGS,
		PTR_ShootTraverse))
	{
		switch(PuffType)
		{
			case MT_PUNCHPUFF:
				S_StartSound(t1, SFX_FIGHTER_PUNCH_MISS);
				break;
			case MT_HAMMERPUFF:
			case MT_AXEPUFF:
			case MT_AXEPUFF_GLOW:
				S_StartSound(t1, SFX_FIGHTER_HAMMER_MISS);
				break;
			case MT_FLAMEPUFF:
				P_SpawnPuff(x2, y2, shootz+FixedMul(slope, distance));
				break;
			default:
				break;
		}
	}
}

I see it setting up the global variables for damage and the targeted mobj, but I don't see where it actually deals any damage to the target.

P_PathTraverse doesn't reference shootthing nor la_damage, and P_TraverseIntercepts, called by P_PathTraverse, doesn't either.

[Graf Zahl]

Gez said:

That's not how you're ever going to fix the issue in a faithful way.



P_LineAttack:

void P_LineAttack (mobj_t *t1, angle_t angle, fixed_t distance, fixed_t slope, int damage)
{
	fixed_t         x2, y2;

	angle >>= ANGLETOFINESHIFT;
	shootthing = t1;
	la_damage = damage;
	x2 = t1->x + (distance>>FRACBITS)*finecosine[angle];
	y2 = t1->y + (distance>>FRACBITS)*finesine[angle];
	shootz = t1->z + (t1->height>>1) + 8*FRACUNIT;
	shootz -= t1->floorclip;
	attackrange = distance;
	aimslope = slope;

	if(P_PathTraverse(t1->x, t1->y, x2, y2, PT_ADDLINES|PT_ADDTHINGS,
		PTR_ShootTraverse))
	{
		switch(PuffType)
		{
			case MT_PUNCHPUFF:
				S_StartSound(t1, SFX_FIGHTER_PUNCH_MISS);
				break;
			case MT_HAMMERPUFF:
			case MT_AXEPUFF:
			case MT_AXEPUFF_GLOW:
				S_StartSound(t1, SFX_FIGHTER_HAMMER_MISS);
				break;
			case MT_FLAMEPUFF:
				P_SpawnPuff(x2, y2, shootz+FixedMul(slope, distance));
				break;
			default:
				break;
		}
	}
}

I see it setting up the global variables for damage and the targeted mobj, but I don't see where it actually deals any damage to the target.

P_PathTraverse doesn't reference shootthing nor la_damage, and P_TraverseIntercepts, called by P_PathTraverse, doesn't either.

The actual function doing the work is PTR_ShootTraverse which is passed as a callback to P_PathTraverse and for which all those global variables are there.

[Gez]

No wonder I missed it, I haven't used pointers to functions for years. (And when I did, I was told "don't do that, it's awful" :p).

In a roundabout way, PTR_ShootTraverse ends up calling P_DamageMobj to deal the damage; which lets us go back to the "P_DamageMobj thrusts unless there's the flag, and the flag ain't here" issue...

[Graf Zahl]

Gez said:

No wonder I missed it, I haven't used pointers to functions for years. (And when I did, I was told "don't do that, it's awful" :p).

... yeah, and the idiots saying that then define languages like Java where you can't do it and some things that should be simple become a major chore...

Reminds me of the age-old 'goto' discussion.

[Reisal]

Hellbent said:

Because the BFG just seems a bit too powerful with that bug fix.

Set the BFG damage to 75 with a Dehacked patch?

[ReFracture]

Hellbent: Is this primarily for single or multiplayer?

If you want to just play singleplayer, and you want a more vanilla like experience, you could always use PrBoom-Plus, edit the .cfg and put in your resolution. There is a field of view variable as well for widescreen.

As for multiplayer, just about every other engine that is somewhat faithful has netcode that makes it impractical. I guess you could try odamex.

When I first realized just how different ZDoom is, it kinda pissed me off as well, but i've learned to live with it. Progress requires sacrifice, and as Graf Zahl mentioned, the original Doom engine is a mess, with things that are broken that we consider a part of the game.

[entryway]

http://prboom-plus.sourceforge.net/test189.zip

This level (negative damage in deh) works differently in compatible ports (prboom\+) and gzdoom. Probably you will want to fix it.

EDIT: Vanilla works like prboom, but has mad palette change in addition