TR1X

TR1X copied to clipboard

https://user-images.githubusercontent.com/4934209/141695425-c3f6512c-8d7c-4e3a-bf27-02a0ef556415.mp4

Save state: saveuba.zip

Can't test in TombATI too easily but I haven't seen this bug in any TRUB media where TombATI is used.

I can't reproduce this issue on my virtual machine or on wine. @oziphantom could you look into it with your debugger? You detected a stack corruption once :) @Richard-L are you using stock 1.3.0?

nothing showing up in VS, I'm was running basically 1.3.0 + 60fps for the test.

Yeah latest release.

I did replace the level's PHD from the stock EU TRUB release btw. So it's no longer the file that comes with TombATI v1.7.

Would that at all make a difference? Do I upload the PHD here?

running a different level file is a massive change. which version did you change it to?

The one I mentioned. PHD from the original UB release in 1998. TombATI uses a custom one with fan-made music triggers worked in. I wanted the vanilla experience.

Unfortunately I don't have that file. Can you share it? To my knowledge UB is freeware so I don't think sharing it is an issue.

Oh good point! I forgot they had made it freeware since I'm always using the original CD. Will upload when I get home.

Okay so END.PHD is the level file in question. I cannot reproduce the freeze either when using TombATI's one. In fact I can hear that there's a music trigger in the moment of the freeze. A bit surprising, because there were many triggers before in the other levels which never caused a crash.

Anyway, the original UB file is this: END.zip CRC32: CC0F7099 Date Modified: 1998-01-30 13:13:28

TombATI's: CRC32: 80E86A5F Date Modified: 2016-03-06 00:51:46

I presume TombATI uses the modified PHDs by Sardoc. Seems to roughly line up date wise: https://www.tombraiderforums.com/showthread.php?t=213223

finally got it to crash

>	Tomb1Main.dll!T_RemovePrint(TEXTSTRING * textstring) Line 286	C
 	Tomb1Main.dll!Overlay_DrawAmmoInfo() Line 310	C
 	Tomb1Main.dll!Overlay_DrawGameInfo() Line 413	C
 	Tomb1Main.dll!DrawPhaseGame() Line 49	C
 	Tomb1Main.dll!GameLoop(int demo_mode) Line 76	C
 	Tomb1Main.dll!GF_InterpretSequence(int level_num, GAMEFLOW_LEVEL_TYPE level_type) Line 956	C
 	Tomb1Main.dll!GameMain() Line 100	C
 	Tomb1Main.dll!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * lpCmdLine, int nShowCmd) Line 233	C

the function

void T_RemovePrint(TEXTSTRING *textstring)
{
    if (!textstring) {
        return;
    }
    if (textstring->flags & TF_ACTIVE) {
        textstring->flags &= ~TF_ACTIVE;
        TextStringCount--;
    }
}

so textstring is 0xffffeacc which doesn't look legal to me, not sure that it is a dangling pointer strictly maybe corruption from something else.

Here's what I got from Process Monitor. Says it encountered a buffer overflow in TombATI's track60.flac. I could only get the game to crash using the original UB level file and the save provided. Whenever I performed the jump on my system, it worked fine. Maybe this is related to #261?

Process Monitor Crash Image

Maybe it's not related to the music. I removed track60 and played the level, and it still crashed.

I used the DOZY cheat to swim down that jump, and the game didn't crash. Then I used Dozy to get over the jump and dropped Lara in a freefall, and the game crashed.

Process Monitor is showing the Process Exit operation exited with SUCCESS. Maybe I'm missing something.

Ah had to go in Event Viewer to see the application error. Exception code: 0xc0000094 is integer division by 0.

Log Name:      Application
Source:        Application Error
Date:          12/11/2021 12:11:09 PM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DESKTOP-xxxx
Description:
Faulting application name: Tomb1Main.exe, version: 0.0.0.0, time stamp: 0x61b4db9b
Faulting module name: Tomb1Main.exe, version: 0.0.0.0, time stamp: 0x61b4db9b
Exception code: 0xc0000094
Fault offset: 0x00041c06
Faulting process id: 0xea4
Faulting application start time: 0x01d7eeb210332c01
Faulting application path: C:\Program Files (x86)\Steam\steamapps\common\Tomb Raider (I)\Tomb1Main.exe
Faulting module path: C:\Program Files (x86)\Steam\steamapps\common\Tomb Raider (I)\Tomb1Main.exe
Report Id: d125518f-9c36-46dc-b1a9-db8931e343be
Faulting package full name: 
Faulting package-relative application ID: 
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>100</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2021-12-11T17:11:09.8039105Z" />
    <EventRecordID>912</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>DESKTOP-xxxx</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Tomb1Main.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>61b4db9b</Data>
    <Data>Tomb1Main.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>61b4db9b</Data>
    <Data>c0000094</Data>
    <Data>00041c06</Data>
    <Data>ea4</Data>
    <Data>01d7eeb210332c01</Data>
    <Data>C:\Program Files (x86)\Steam\steamapps\common\Tomb Raider (I)\Tomb1Main.exe</Data>
    <Data>C:\Program Files (x86)\Steam\steamapps\common\Tomb Raider (I)\Tomb1Main.exe</Data>
    <Data>d125518f-9c36-46dc-b1a9-db8931e343be</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

I'm 95% convinced this is clipping pushing in more polygons, when it crashed for me there was a section of the wall remove, so if a large polygon got clipped that was at the end of list it could overflow some buffer somewhere. We know it does bad things, and the crash is very positional.

This looks hard. Do we want to keep it in 2.1 or do we postpone it till later?

I vote to push it down the line. I have only tried to debug when/what the error is. No work towards a fix.

Move it down I agree. Few people make it to UB, and even fewer are as particular on using original retail assets as I am 😉

Apparently there is a bug with the original level file, and the level file with music cues added fixed it. Seems like this user on TRF made the music cue level files and fixed the issue. They made a fixed version without the music added but that link doesn't work anymore.

The crash is also mentioned on Stella's walkthough.

So I asked SuikazeRaider, and I think he knows why it happens. Forwarding what he told me below.

From: https://trtranslationsworld.wordpress.com/2021/06/01/news-2021-06-01/

An important bug from the level “Atlantean Stronghold” has been fixed. Lara’s jump could crash the game because two rooms of this level were jointed in a wrong way.

https://cdn.discordapp.com/attachments/830784934133891093/930213236362588170/1-1-2-1-04.png

the problem is in the alternate room the room-door is so high being an illegal door. I needed to down it and ajust the vertices and ceiling values.

Also @walkawayy I think Sardoc's release is this (for reference): https://www.tombraiderforums.com/showthread.php?t=213223

I think there are three possible fixes to this:

• update our UB levels to a version that presents no such issue. This is less than ideal, because people may play with outdated / other level files either because of unawareness, or the will to play with other variants of the levels.
• investigate the nature of the crash and make a workaround. It might not be possible, for instance in case we need to fix the portals in a way that cannot be easily figured out by a machine.
• add a gameflow instruction that works similar to FixPyramidSecretTrigger.

I prefer the second approach, then the third.

Sadly I don't experience this crash so I don't really know how to work on it.

The level provided with TR1Main works. This jump only breaks using an original Unfinished Business level. The version with music added fixes it, and there's a non music version with a fix.

Hej rr-!

This bug is a bit random. The jump crash is caused by the wrong connexions between the rooms # 74 and # 12. Check the door connexions between the # 5 and # 12 to get the correct values. In the # 74 ones, the doors are 256 units higher (1 click / 0.25 blocks) Fixing the doors the crash is solved. For my project, I've fixed the vertices and the ceiling values too, but only with the door one it works fine.

I assume the Music Version by Sardoc adds an old fix that adds a flip trigger in the room # 8, just like the TRUB PSX port by b122251.

Kind Regards!

@rr- I think this can be closed now? Thanks to #518 there's a proper error crash and exit with some log info. The original UB level file can't be fixed without changing the level file itself. There's already fixes out there that come with TombATI and a version without the added music triggers.

I think so but it would be good to confirm if it was this bug in fact and not something else. The offending file is posted somewhere above as END.zip.

So what SuikazeRaider suggested is fixing the level file itself?

Why did this crash not occur on vanilla DOS TR1 UB?

It's a bit regrettable if the original level asset file cannot be used, but instead a fan version is mandatory. What if I don't want all the music triggers someone added?

Is the DOS version using the same version as the PC port? If yes and we know for sure that it doesn't crash, I would like to take a peek at how the DOS version managed that. It'll take me a while though to figure since I don't have anything mapped in the DOS version.

I can do some research and try myself, but I used the asset files from 1998 (attached above somewhere iirc). Surely this crash would've been more known had it existed back then, as it's an iconic jump, and if it did crash people wouldn't have been able to complete UB.

I think the crash was introduced with TombATI.

So are the level files identical for the DOS version or not?

Was there ever a "pc port" other than TombATI later? I think there was only the release intended to be played under DOS, which then worked from within Win95/98 too. There were then also the numerous patches for the wild west of 3d graphic cards of the time. For UB I don't know how many exist, I would assume only the 3dfx one, but nevertheless the level asset file END.PHD is entirely unaffected by all this (!)

There are two (original) retail UB releases for the UK and US markets respectively https://secretsrunner.web.fc2.com/data_top/tr_top.html

• EIDOS PREMIER COLLECTION Tomb Raider Unfinished Business for UK
• EIDOS Tomb Raider GOLD Trapezoid Box release: /March/1998

If you check the screenshots UK / US, you can see "Atlantean Stronghold" comes in both END.PHD and END.TUB, each time with the same last modified timestamp on the files. The level files weren't touched before going into retail on either release, and they also match with the files I have. I had uploaded END.PHD above but here are both the PHD and TUB again: atlantean-stronghold_original-ub-release.zip

I don't know what the .tub is for tbh. It doesn't seem to be used, ever?

You then have at least 2 (possibly even 3) fan releases containing modified UB level assets with added music triggers (and apparently more changes that remedy the crash of this issue), of which the one TombATI decided to bundle is the most widespread one.

I'd say we would need to test on DOS to confirm this didn't crash. Maybe the OS handled the overflow differently? No idea how to test though.

Here's a thread on the crash from 2006: https://www.tombraiderforums.com/showthread.php?t=72013

I think TombATI wasn't released until 2016 based on this thread date? https://www.tombraiderforums.com/showthread.php?t=214779&highlight=tombati

Hmm, that 2006 topic was helpful. It sounds as though this did actually crash on DOS. I'll see if I can bring myself to play all the way to this point on DosBox. Will check if DOS had level skip cheats. You'd think so.

In the last post of the topic someone mentioned this which is interesting:

You can take the normal running jump to the hole, but save in the middle of falling. Then load again and you'll fall into the pool without crash

Could be worth testing in TR1M also.

I also dug up the broken link to Stella's site that was referenced: https://tombraiders.net/stella/walks/TRUBwalk/03stronghold.html#:~:text=BUG%20FIXES%20FOR%20GAME%20CRASH/GRAPHICAL%20GLITCH%20WHEN%20JUMPING%20INTO%20THE%20PYRAMID%3A

It would seem this was a thing.

More importantly: do we know what causes the crash in the first place? Is it worth adding a workaround to TR1M so that native (and potentially bugged) retail asset files can be used? I would hope yes :innocent: