FP precision crushing the player on buttons

Discuss programming topics for the various GPL'd game engine sources.

Moderator: InsideQC Admins

FP precision crushing the player on buttons

Postby ericw » Wed Apr 18, 2018 6:37 am

We had a report that, on 64-bit builds of Quakespasm, players were getting crushed when pressing angled buttons in some custom maps/mods: *
- Travail's qte1m2.bsp: noclip to 2788 732 -584, and press the button. The player will get crushed and killed on affected engines.
- sm179_otp.bsp: pressing the left button causes the player to get stuck.

The above happens on 64-bit QS builds (Windows x64, macOS builds) but also Fitzquake 0.85 compiled with VS2017. It'll probably happen on anything but gcc/msvc building for x86 without SSE.

I've posted about 80-bit x87 vs C standard compliant FP precision behaviour differences before (e.g. lightmaps:
) so I knew what to expect, it was going to be some FP sensitive code (probably a dot product) that worked fine with 80-bit temporaries but "broke" with 32-bit rounded temporaries.

The culprit - whether the button worked normally or crushed the player - turned out to be this bit of code in SUB_CalcMove (subs.qc):
Code: Select all
// calculate length of vector
        len = vlen (vdestdelta);

// divide by speed to get time to reach dest
        traveltime = len / tspeed;

        if (traveltime < 0.1)

traveltime would be very near 0.1, and the "if" branch would either be taken or not causing the crushing or not.

The source of the FP precision difference based on the compiler settings was PF_vlen:
Code: Select all
void PF_vlen (void)
   float   *value1;
   float   new;
   value1 = G_VECTOR(OFS_PARM0);

   new = value1[0] * value1[0] + value1[1] * value1[1] + value1[2]*value1[2];
   new = sqrt(new);

The fix was:
Code: Select all
-   float   new_temp;
+   double   new_temp;
    value1 = G_VECTOR(OFS_PARM0);
-   new_temp = value1[0] * value1[0] + value1[1] * value1[1] + value1[2]*value1[2];
+   new_temp = (double)value1[0] * value1[0] + (double)value1[1] * value1[1] + (double)value1[2]*value1[2];

After tracking down and "fixing" enough instances of the same bug in response to reports from users, I'm thinking all math temporaries where the precision could matter should just have casts added preemptively.

[*] QS issue / commit links:
Posts: 91
Joined: Sat Jan 18, 2014 2:11 am

Re: FP precision crushing the player on buttons

Postby Baker » Wed Apr 18, 2018 3:17 pm

That's a great bug fix.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
User avatar
Posts: 3661
Joined: Tue Mar 14, 2006 5:15 am

Return to Engine Programming

Who is online

Users browsing this forum: No registered users and 1 guest