[Fixed] Old bugs not yet fixed

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Post by randi »

Okay, fixed them both. For 1, I put back the BSP-based sight traversal that came with the Doom source. It can be slower than the blockmap-based version that Heretic and Hexen used, but it's more accurate. For 2, I changed the check so that it won't load STCFN121 unless STCFN120 and STCFN122 are also present.
Hyena
Posts: 69
Joined: Mon Oct 27, 2003 1:31 pm
Location: The Death Orb of Planet Peehole

Post by Hyena »

Thanks a lot, Randy! :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49071
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Regarding the sight check, after being told that in E1M3 of Doom this error occurs I did some checks and what I found was quite surprising:

It's neither a blockmap bug nor is the blockmap sight check algorithm inaccurate. I think this qualifies as a genuine bug. P_PathTraverse has the same problem which I was able to confirm with a few tests.

Code: Select all

	for (count = 0 ; count < 64 ; count++)
	{
		if (!P_SightBlockLinesIterator (mapx, mapy))
		{
			return false;	// early out
		}

		if ((mapxstep | mapystep) == 0)
			break;

		if ( (yintercept >> FRACBITS) == mapy)
		{
			yintercept += ystep;
			mapx += mapxstep;
			if (mapx == xt2) mapxstep = 0;
		}
		else if ( (xintercept >> FRACBITS) == mapx)
		{
			xintercept += xstep;
			mapy += mapystep;
			if (mapy == yt2) mapystep = 0;
		}
// added this for checking
		else
		{
			Printf("P_CheckSight failed\n");
			break;
		}

	}
The problem is that the function occasionally runs into the 'else' branch with the Printf I have added for testing. This happens when the trace wants to change both the x- and y- blockmap coordinate at the same time. Normally *both* adjoining blocks should be checked in this instance. This code just screws up, however. What I find most disturbing in this instance is id's 'fix' to limit the iterations of this loop. Somehow I get the feeling that somebody was fundamentally unaware what he was doing (not that it surprises me with Doom's source. :( )

Theoretically this bug should make it possible in rare situations to shoot through walls although I never managed to do it.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Post by randi »

Thanks for finding that. After fixing it, the problem goes away, so I can use the faster blockmap-based sight checks after all.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

Yay, maybe my phantom E1M3 bug that no one else seems to have will finally be fixed. :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49071
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

It will. After I fixed this E1M3 worked perfectly. After all, that's what I used to find it.
Post Reply

Return to “Closed Bugs [GZDoom]”