Wipeout 3 SE [SCES02845] gets stuck on initial loading screen (possible fix included)
BodbDearg opened this issue · comments
Describe the bug
With more recent versions of PCSX-Redux I discovered that Wipeout 3 Special Edition will get stuck on the initial loading screen and never proceed past that point. The 'loading' message continues to animate but the game never progresses to the main menu. Looking at the emulator logs also reveals read errors being continually logged.
Because I am building from source, I was able to track down the commit where this problem was introduced:
31692da
And specifically it appears to be due to the changes made to:
src/cdrom/cdriso-cue.cc
After some debugging I found that the game was attempting to read negative sector numbers and with further investigation I may have found a potential fix:
diff --git a/src/cdrom/cdriso-cue.cc b/src/cdrom/cdriso-cue.cc
index e7a8842f..831b33f1 100644
--- a/src/cdrom/cdriso-cue.cc
+++ b/src/cdrom/cdriso-cue.cc
@@ -130,6 +130,9 @@ bool PCSX::CDRIso::parsecue(const char *isofileString) {
}
cue.cfilename = cuename.string().c_str();
CueParser_construct(&parser, &disc);
+ // The cue parser doesn't include the disc header (150 sectors) in its LBAs but pcsx-redux does.
+ // This fixes issues starting Wipeout 3 Special Edition.
+ parser.currentSectorNumber = 150;
CueParser_parse(&parser, &cue, &scheduler, createFile,
[](CueParser *parser, CueScheduler *scheduler, const char *error) {
Context *context = reinterpret_cast<Context *>(scheduler->opaque);
Prior to 31692da the src/cdrom/cdriso-cue.cc file started parsing tracks at sector number 150 so this appears to revert it back to the previous behavior. See:
pcsx-redux/src/cdrom/cdriso-cue.cc
Line 75 in e78a240
I've tested this fix with Wipeout 3 SE and it seems to be working correctly. I also tested with PSX Doom and that also appears to be OK. Obviously requires more extensive testing/vetting etc.
Expected behavior
The game should load to the main menu.
Steps to reproduce the bug
Run Wipeout 3 Special Edition [SCES02845] with either Open Bios or SCPH1002 bios and observe that the game gets stuck on the initial loading screen.
Operating System
MacOS Big Sur (11.6.6)
PCSX-Redux version
CPU model
2.8 GHz Quad-Core Intel Core i7
GPU model & Drivers
NVIDIA GeForce GT 750M 2 GB and Intel Iris Pro 1536 MB
BIOS version
SCPH1002
Options
- Dynarec CPU
- 8MB
- OpenGL GPU
- Fastboot
- Debugger
Iso checks
No response
Logs
No response
Additional information
No response
Uuuuh, that's... weird. Without the fix, could you put a screenshot of what you have in the iso browser for your iso?
Also, could you share the .cue file for it?
Sure thing, here's the output of the Iso Browser and the screen that it gets stuck on:
And here is the .cue file:
W3SE.cue.zip
Right, so, the cue parser is correct, as it's parsing LBAs from the beginning of the disc, which are indeed offset by 150. The mistake is in the assignment later. I'm surprised this is only biting me now.
Right, so, the cue parser is correct, as it's parsing LBAs from the beginning of the disc, which are indeed offset by 150. The mistake is in the assignment later. I'm surprised this is only biting me now.
Yeah it seems odd that a bug like this doesn't affect more titles. There must be something very particular with how this game is handling IO that causes it to be an issue. Just checked the latest build in any case and it looks like all is well now, thanks for putting in that fix!
So the way this one title does it is request the start of the track 1 using GetTD(1), which is a very odd thing to do as it's not really supposed to change from 00:02:00. Of course, this returned 00:00:00 instead of 00:02:00, which most other games will have otherwise hardcoded.