[Fixed] Old bugs not yet fixed

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Postby randi » Sat Nov 01, 2003 8:09 pm

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.
User avatar
randi
Site Admin
 
Joined: 10 Jul 2003

Postby Hyena » Sun Nov 02, 2003 2:26 pm

Thanks a lot, Randy! :)
Hyena
The Super Hero for your gums.
 
Joined: 27 Oct 2003
Location: The Death Orb of Planet Peehole

Postby Graf Zahl » Thu Nov 13, 2003 4:49 am

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 allExpand view
   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
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby randi » Fri Nov 14, 2003 3:38 pm

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
randi
Site Admin
 
Joined: 10 Jul 2003

Postby HotWax » Fri Nov 14, 2003 4:40 pm

Yay, maybe my phantom E1M3 bug that no one else seems to have will finally be fixed. :)
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 19 Jul 2003
Location: Idaho Falls, ID

Postby Graf Zahl » Fri Nov 14, 2003 4:50 pm

It will. After I fixed this E1M3 worked perfectly. After all, that's what I used to find it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Previous

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests