PCSX2
[BUG]: Crash Tag Team Racing - Random game crashes on load screens
Describe the Bug
In Crash Tag Team Racing, the game will often crash when exiting and re-entering the park. On real PS2 hardware, this issue was known but only resulted in being sent back to the PS2 browser, and it occurred significantly less often.
On PCSX2, however, this crash is significantly more frequent, and sometimes results in a black screen. This appears to be tied to the loads between different parts of the game that run at different framerates (e.g., the park runs at 30 FPS, while menus and minigames run at 60 FPS).
There is a 60 FPS patch for the game and setting the EE Cycle rate to 180% (overclock) completely prevents the game from crashing on emulator, which helps my theory of it being tied to a possible timing instability or desync during FPS changes when exiting and re-entering the park.
Reproduction Steps
- Use default settings
- Exit and re-enter the park constantly
Expected Behavior
- You get sent into the PS2 browser upon exiting or re-entering the park
- You get a black screen upon exiting or re-entering the park
PCSX2 Revision
v2.3.337
Operating System
Windows 11
If Linux - Specify Distro
No response
CPU
Ryzen 9 8945HS
GPU
RTX 4070M
GS Settings
No response
Emulation Settings
No response
GS Window Screenshots
No response
Logs & Dumps
- A log file I got when I got sent to the PS2 browser right after the game crashed.
Ran some tests, the game's propensity to crash seems directly related to how high its internal framerate is on the loading screen. I ran the game in a debug build and loading screens and the menus were consistently flooding the console with:
GS transfer buffer overflow len 128 remaining 64, tex_size 64 tw 8 th 8 bpp 8
This behaved differently in debug compared to release, where the internal framerate would get floored down to 10 FPS on loading screens. In release, it would run all the way at vsync rate. In debug, it never once crashed.
So, I thought I would try forcing the framerate down to see if that helped. Disabling Instant VU1 almost completely resolves the issue by causing framerate on loading screens to dive down to 10 FPS. I was still able to get a crash or two, seemingly from some RNG whether the framerate drops enough or not.
From what people say about a 60 FPS patch fixing this game, I am left to guess it modifies something about the game's framerate control behavior where it eliminates whatever horrific evil this game is doing when trying to run a loading screen.
I once tried disabling Instant VU1 and it constantly crashed on me, but perhaps my RNG was bad when I tested it. At one point, I tried underclocking the game by messing with the EE Cycle Rates and that did fix the crashing, but at the cost of increased lag throughout the game. This would be fine but the CTTR speed running community allows pcsx2 for speed runs, so we can't allow it. That being said, I will do some more testing with Instant VU1 tomorrow if I get the chance to. Thank you for the testing and explanations.
My crackpot theory after looking at this further is that the devs could have been counting frames, not vsyncs, as a timing mechanism. I have no sources to back this up besides observation, but this feels like the higher the framerate goes, the more likely it is to die.
It feels like the game is trying to hurl garbage at the VUs or GS in order to slow the system down. This would at least corroborate the framerate plummeting on the loading screen when the game is doing nothing. My crackpot theory is the devs purposely did this to slow down the PS2, to buy time for the game to load in the background, while they counted the number of frames elapsed and assumed after x frames the game would have finished loading from disc and/or memory card. Loading from a memory card is at the mercy of the IOP, so if they need data from the memory card, there is no choice but to wait for it.
What doesn't make sense at all and why this is crackpot, is in what universe is counting the number of frames elapsed while completely detached from vblanks is remotely okay. Perhaps the PS2 was consistent enough that it worked most of the time? But if this crackpot theory is true then basically everything about PCSX2 is working against this game. This basically means the game would have had to have an unbound framerate in the menus and loading screens, running a while loop completely detached from any vblanks and just spitting out frames as fast as possible, and on hardware hoping the VUs and GS processing junk would take enough time for IOP communication to finish loading from disc and/or memory card. It makes no sense, and yet it's the only explanation I can conjure up.
I don't suppose anyone's reverse engineered this game and actually has a non-crackpot idea?
After some testing with Instant VU1 disabled and default settings everywhere else, the game still crashes on me a ton, but that could be due to really bad RNG with the FPS drops.
Regarding your last question, I don't think anyone has reversed engineered this game, although some might have tampered with the games files. I once tried messing with the games files but I didn't get very far.
That being said, do you think it'd be possible to modify the existing 60fps patch such that we retain the games original frame rate (i.e. 30fps in the park and car events, and 60fps in the main menu and mini-games) while also making sure the FPS remains stable throughout each load so that it doesn't cause the game to randomly crash?
Double checking, I'd put both lines of code into a file and name it "SLUS_21191.pnach"? Or would it be something else?
You are missing the CRC. Get that from the emulator itself. The filename should be SLUS-XXXXX_CRC.pnach.
@RedPanda4552 My theory differs from yours.
I think that rather it relates to the ee loading data the iop has yet to deliver. Increasing the ee's clock rate to 300%, combined with frequently clicking buttons during the loading menus (which slows down the iop), drives the game to shut itself down after loading incorrect data. Conversely, lowering the clock rate prevents the problem. Therefore I imagine that the game doesn't validate the data before it loads it, but does so afterwards, panics, and shuts itself down, but I can't prove that though.
Having said that I don't see how PCSX2 could fix a game bug. My patch adds a 0x7000 delay during loading screens only. But because it adds a slight lag by doing so, I don't see how it could be added to the gameDB.
Conclusively, though, no one is to blame for this glitch other than the game's developers.
@ibdiab Can you check if this patch works for you? I've tested it 5 times now, with it working well but I need others to verify it works. SLUS-21191
patch=1,EE,00270754,word,0C03FE80 patch=1,EE,000FFA00,word,24027000 patch=1,EE,000FFA04,word,2442FFFF patch=1,EE,000FFA08,word,1440FFFE patch=1,EE,000FFA10,word,0809BD38
After a lot of testing (without and with the patch that unlocks the extra PSP content), I only got the game to crash once, and that was because I spammed the "X" and "triangle" buttons so hard that it lowered the FPS just enough that it crashed. But generally, I don't think anyone will be spamming buttons during the loads. That being said, having a couple more testers would be greatly appreciated. I can also get some friends to test it. Thank you for making the patch.
In regards to Slayer0fRA's comment, I did try lowering the EE cycle rate and EE cycle skipping and that did fix the issue, but it added extra lag to the game, which is an issue for speedruns. That being said, I do plan to test it with some settings turned off like "Fast Boot" and "Enable MTVU", since that generally makes the game more accurate when compared to real hardware for speedrunning. If anyone can test it with the PSP car patch and these settings, that'd be greatly appreciated.
Also, can I share your patch with the OG Crash Speedrunning discord if possible? I'll make sure to credit you of course.
@ibdiab Of course, feel free to share :)
It seems the patch luckily didn't slow down the game. If it did, it's hardly noticeable, which is why I decided to change the delay from 0x7000 to 0xffff.
Testing shows that: Without the patch, the game loads within 6.5 seconds. With it, 6.8 seconds.
This should do the trick even in a session of ultra button spamming.
patch=1,EE,00270754,word,0C03FE80 patch=1,EE,000FFA00,word,3442FFFF patch=1,EE,000FFA04,word,2442FFFF patch=1,EE,000FFA08,word,1440FFFE patch=1,EE,000FFA10,word,0809BD38
@Slayer0fRA I'll test the new patch you made, but I don't think anyone is gonna ultra spam it that hard. After all, I did already tell everyone in the speedrunning community that button spamming crashes the game. Nonetheless, I'll give this one a try later today.
After a ton of testing, which includes: exiting and re-entering the park a bunch, doing some races & mini-games, doing battle/stunt arenas, and even watching some FMV and in-game cutscenes, I couldn't get the game to crash at all. Thank you @Slayer0fRA for the new cheat, it works very nicely. That being said, I think having a couple more people test it to ensure nothing crashes and everything works is greatly encouraged. Thank you again @Slayer0fRA
@ibdiab Of course, feel free to share :)
It seems the patch luckily didn't slow down the game. If it did, it's hardly noticeable, which is why I decided to change the delay from 0x7000 to 0xffff.
Testing shows that: Without the patch, the game loads within 6.5 seconds. With it, 6.8 seconds.
This should do the trick even in a session of ultra button spamming.
patch=1,EE,00270754,word,0C03FE80 patch=1,EE,000FFA00,word,3442FFFF patch=1,EE,000FFA04,word,2442FFFF patch=1,EE,000FFA08,word,1440FFFE patch=1,EE,000FFA10,word,0809BD38
A small question, what will be the impact if this patch is used at the same time with the 60fps(180%) patch?
@crashGG It will not affect the 60 fps patch. If it did, it would only affect it during the loading screens. You can safely use both together.
The 60fps patch fixes the crashing entirely, even without this cheat. So therefore, if your using the 60fps patch, you don't need to use the cheat. The cheat was only made to fix the issue when not using the 60fps patch.