TR1: Exploding mummy kills Lara even when far away

[absolutelynothinghere]

Hello again, sorry to bother you with all these issues.

In the TR1 level "Obelisk of Khamoon" there are mummies that explode when killed, dealing damage to Lara unless she is sufficiently far away. In TR1X these mummies always insta-kill Lara even when she is far away.

As you can see in the video below, Lara is standing on one end of a bridge while a mummy stands on the other end, just within her line of fire. When Lara shoots the mummy and it explodes, she immediately dies despite standing far away with full health.

The save file from the video: save_tr1_11.dat.gz

https://github.com/user-attachments/assets/3256a8db-b6a2-43fc-9525-a03ffc8c80db

[Richard-L]

Sadly the video is bugged for me. Mostly just shows black (?)

[absolutelynothinghere]

Ok do either of these videos work?

mummy_bomb_vp9+opus.webm

mummy_bomb_vp9+vorbis.webm

[Richard-L]

Yep, both work. Thanks for updating 👍

[lahm86]

I can't replicate this with the provided save (or otherwise). Is it the latest build where this happens for you, and is it Windows, Linux or Mac?

Edit: I see it is 4.5.1 from your video.

[absolutelynothinghere]

It's version 4.5.1 on Linux, I compiled it myself using Zig CC. If you'd like the library versions used I can put together a list.

My executable is here: TR1X.gz

[absolutelynothinghere]

Update: I just recompiled version 4.5.1 with no optimizations (-O0) and the problem seems to have been fixed... I guess that helps?

[yoqto]

I threw your binary into a docker container and can confirm Lara dying with your binary. My local build with GCC 14.2.1 and -O3 does not kill Lara when the mummy goes down on your save. So it seems your compiler is messing up in some of its optimizations.

[absolutelynothinghere]

That makes sense, thank you. The problem persisted with -O2 and even -O1 so I suppose -O0 is the way to go...

[rr-]

Let's keep this open. We can't have platform-dependent arithmetic in our code.

[yoqto]

Beware, armchair debugging:

• When the mummy dies, it calls Effect_ExplodingDeath with damage 0x7FFF (32767 decimal). That's way more than one of Torso's parts (250) or a centaur's (100).
• A bit later, BodyPart_Control calls Lara_IsNearItem with distance being 65534 (damage * 2 via damage being stored as the effect's counter).
• SQUARE(distance) in Item_IsNearItem is 4294705156 (aka -262140 for int32_t).
• With Zig 0.13.0 and Clang 19.1.2, the SQUARE(x) + SQUARE(z) <= SQUARE(distance) part of the if in Item_IsNearItem passes -> Lara takes damage from multiple (all?) body parts as they're deemed close enough to her.
• With GCC 14.2.1, however, this is not the case. Maybe 65534^2 is stored in a 64bit register? Neither C nor x86 asm are my strong suit, much less efficiently debugging them. At any rate: no significant damage is dealt and Lara lives.

Declaring the distance parameter of Item_IsNearItem as uint32_t lets Lava live when built with any of the three compilers on my machine. Hope this helps?!

[rr-]

Thank you @yoqto that is really helpful! We'll aim to include a fix in the next release.

[absolutelynothinghere]

I tried the solution described by @yoqto and it indeed solves the problem!

Here's a patch for TR1X 4.5.1:

--- a/src/tr1/game/items.c
+++ b/src/tr1/game/items.c
@@ -314,7 +314,7 @@
     return changed;
 }

-bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, int32_t distance)
+bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, uint32_t distance)
 {
     int32_t x = pos->x - item->pos.x;
     int32_t y = pos->y - item->pos.y;
--- a/src/tr1/game/items.h
+++ b/src/tr1/game/items.h
@@ -25,7 +25,7 @@
 int32_t Item_GlobalReplace(
     GAME_OBJECT_ID src_object_id, GAME_OBJECT_ID dst_object_id);

-bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, int32_t distance);
+bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, uint32_t distance);
 bool Item_Test3DRange(int32_t x, int32_t y, int32_t z, int32_t range);
 bool Item_TestBoundsCollide(ITEM *src_item, ITEM *dst_item, int32_t radius);
 bool Item_TestPosition(

[rr-]

I tried the solution described by @yoqto and it indeed solves the problem!

Here's a patch for TR1X 4.5.1:

--- a/src/tr1/game/items.c
+++ b/src/tr1/game/items.c
@@ -314,7 +314,7 @@
     return changed;
 }

-bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, int32_t distance)
+bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, uint32_t distance)
 {
     int32_t x = pos->x - item->pos.x;
     int32_t y = pos->y - item->pos.y;
--- a/src/tr1/game/items.h
+++ b/src/tr1/game/items.h
@@ -25,7 +25,7 @@
 int32_t Item_GlobalReplace(
     GAME_OBJECT_ID src_object_id, GAME_OBJECT_ID dst_object_id);

-bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, int32_t distance);
+bool Item_IsNearItem(const ITEM *item, const XYZ_32 *pos, uint32_t distance);
 bool Item_Test3DRange(int32_t x, int32_t y, int32_t z, int32_t range);
 bool Item_TestBoundsCollide(ITEM *src_item, ITEM *dst_item, int32_t radius);
 bool Item_TestPosition(

I'm glad to hear that the solution worked for you! We might explore a slightly different approach for the final solution, however; likely something akin to what we do in Math_GetVectorAngles, since an additional 1 bit of precision might still not be enough for larger level geometries.