Thruster differences between 1.23b33 and now?

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

Thruster differences between 1.23b33 and now?

Postby AlexMax » Mon Mar 30, 2015 8:29 pm

So, I wasn't sure if this was considered a bug or not, but it'd be nice to figure out what is going on here:



This is a video of a particular section of MAP02 of dest_unknown_final.wad recorded with both ZDoom 1.23b33 and GZDoom 1.8.2. In 1.23, this section of the map is trivial as no matter what you do, the thrusters will land you in the correct spot 95% of the time. However, on modern ZDoom, the thrusters seem to land you short of the intended landing spot, and completing the maze seems to be nearly impossible. Similar effects have been noted going back all the way to 2.0.21 (thanks Blzut3).

Both ports are using sv_gravity 800 and sv_aircontrol 0. I also tested this in Zandronum with the compatflag born from this thread, and I still couldn't complete the maze.

Does anybody have any clue what could be going on here? There are numerous maps like these designed for the old physics, and it'd be nice to be able to play them in modern ZDoom ports.

EDIT: Fixed video.
User avatar
AlexMax
Certainly they existed...
 
Joined: 15 Apr 2006

Re: Thruster differences between 1.23b33 and now?

Postby Graf Zahl » Tue Mar 31, 2015 3:32 am

Yes, there was some quite profound change right around that version to the ThrustThing special:

Code: Select allExpand view
FUNC(LS_ThrustThing)
// ThrustThing (angle, force, nolimit)
{
   if (it)
   {
      angle_t angle = BYTEANGLE(arg0) >> ANGLETOFINESHIFT;

      it->momx += arg1 * finecosine[angle];
      it->momy += arg1 * finesine[angle];

---->
      if (!arg2)
      {
         it->momx = clamp<fixed_t> (it->momx, -MAXMOVE, MAXMOVE);
         it->momy = clamp<fixed_t> (it->momy, -MAXMOVE, MAXMOVE);
      }
<----
      return true;
   }
   return false;
}


The marked block had been added and this map falls right into that spot to get affected by it. In addition the function previously didn't add the new velocity, it set it absolutely (using '=' instead of '+=' in the lines above the block.)

So where's the problem: It's simply that the underlying movement code was also changed so just adding a compatibility option is not going to work, this would require quite a bit of fudging to reintroduce several old problems into the movement code. Frankly, I'm not going to bother. The jumps I've tested can all be completed if you run fast enough when the jump gets triggered.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to General

Who is online

Users browsing this forum: No registered users and 6 guests