libretro / LRPS2

GNU General Public License v2.0
165 stars 48 forks source link

Many Games crash after the PlayStation 2 boot animation on Xbox platforms. #162

Closed GABO1423 closed 3 years ago

GABO1423 commented 3 years ago

This issue was caused by PR #160, but rather than actually being a buggy PR, it just leads to an underlying problem the Xbox platforms have when trying to apply the pnach files from the internal databases, further context can be found on the comments of the aforementioned PR. This issue is just for discussing and possible finding a solution without needing to reverse the commit. As requested by @twinaphex, I'll make a debug build of PCSX2 and try to see what the log files can tell us about this.

GABO1423 commented 3 years ago

Here's a log file taken from the core when loading Gran Turismo 4: retroarch2021_09_1619_02_36.log @SeventySixx sorry to bother you again, but when possible, does this file tell you anything about the issue?

SeventySixx commented 3 years ago

uhm... I don't see nothing wrong, if not the initial:

[libretro INFO] Invalid BIOS file: scph39001.bin

anyway it seems that it has not effects, but not sure why this bios log appears here...

At the end of the log file the recompiler seems to not reset right after applying the fix found, it just stops there

I checked the "culprit" SLUS-20983 yaml structure in the GameDb file, I can't see nothing wrong at first sight.

A thing that I would do it's to try to remove all the SLUS-20983 entry, checking so if the problem is due to that entry:

SLUS-20983:
  name: "Musashi Samurai Legend"
  region: "NTSC-U"
  compat: 5
  patches:
    675CEB8F:
      content: |-
        author=Prafull and Kozarovv
        // Fixes almost all problems apart from little translucent fog effect in some areas
        patch=1,EE,001473b0,word,3c04000f
GABO1423 commented 3 years ago

@SeventySixx after making a build with the entry removed, Gran Turismo 4 still crashed after the PlayStation 2 boot logo. retroarch2021_09_1713_32_02.log

GABO1423 commented 3 years ago

After some experimentation, I made a build which only had the GameIndex.h file reverted, leaving the GameIndex.yaml file intact, and Gran Turismo 4 booted without issue. retroarch2021_09_1714_00_01.log

EDIT: Here's the core for those who are curious: pcsx2_libretro.zip

GABO1423 commented 3 years ago

After even more experimentation, the culprit of this issue is most likely the latest Xbox OS update, which resulted in every version of the core made after PR #47 crash after the boot logo. To make matters worse, this results in Automatic Gamefixes being completely broken as you could also gather from the log files, and since some of the fixes (such as the ones related to the Clamping and Round Modes) are required by many games to work correctly, combined with the options in the Quick Menu not being actually functional as a result of the forced Speedhacks preset (Setting it to Safe does not allow you to change some settings including the previously mentioned Clamping and Round Mode settings in standalone, same deal with the core), this results in those games being unplayable in anything but really old core versions that still relied on ini files. Klonoa 2 is a good example, being impossible to play beyond the initial few minutes due to the "Required Objects missing" issue highlighted in the PCSX2 compatibility wiki: https://wiki.pcsx2.net/Klonoa_2:_Lunatea%27s_Veil

covey-j commented 3 years ago

After even more experimentation, the culprit of this issue is most likely the latest Xbox OS update which resulted in every version of the core made after PR #47 crash after the boot logo.

When I wrote PR #47, I did most of my testing on Xbox, so yeah, it could be something like that. Make sure you have the ini files and the folder structure if you're testing those older versions, though, because the Xbox version would crash if certain folders weren't present.

combined with the options in the Quick Menu not being actually functional as a result of the forced Speedhacks preset (Setting it to Safe does not allow you to change some settings including the previously mentioned Clamping and Round Mode settings in standalone, same deal with the core), this results in those games being unplayable in anything but really old core versions that still relied on ini files.

That doesn't sound right. Just because it's greyed out in standalone when you have a preset doesn't mean it works that way in the libretro core. If the round and clamp mode options weren't functional, then #99 would not have gotten the Japanese version of Drakkengard to work correctly (there was no entry in the game DB for that game). I think to change round/clamp mode, you'd probably need to restart the content after selecting the option.

FYI, the tab indentation that was replaced with spaces in #160 came from commit https://github.com/libretro/pcsx2/commit/18207f0f1047e456f09d9ac5679f94cc52e64e3f. Spaces were used there prior to that.

GABO1423 commented 3 years ago

That doesn't sound right. Just because it's greyed out in standalone when you have a preset doesn't mean it works that way in the libretro core. If the round and clamp mode options weren't functional, then #99 would not have gotten the Japanese version of Drakkengard to work correctly (there was no entry in the game DB for that game). I think to change round/clamp mode, you'd probably need to restart the content after selecting the option.

Didn't also sound right for me initially, but the options simply had no effect on Klonoa 2 at all, and as a result of the Xbox update, games always crash without fail after choosing Close Content. And even after that, the problem I mentioned was always present. So quite frankly, I'm just amazed at how badly the core was borked because of what Microsoft described as a simple "stability" update.

covey-j commented 3 years ago

Didn't also sound right for me initially, but the options simply had no effect on Klonoa 2 at all, and as a result of the Xbox update, games always crash without fail after choosing Close Content. And even after that, the problem I mentioned was always present. So quite frankly, I'm just amazed at how badly the core was borked because of what Microsoft described as a simple "stability" update.

This shouldn't have anything to do with the presets, though. As far as I can tell, there isn't any logic in the programming that would cause the preset options to have any effect on the round/clamp modes. I think we can rule that out as the problem.

as a result of the Xbox update, games always crash without fail after choosing Close Content.

^This would explain why the round/clamp options don't work, though. Those options don't take effect immediately. They require a content restart. But if the core crashes on Close Content, then the core options you choose won't get saved for the next boot. So I think the options themselves would work just fine if either Close Content or Restart Content were fixed.

I can't test this hypothesis myself for the foreseeable future (my friend is borrowing my Xbox until I finish my dissertation), but if you'd like test it, here's what you can do:

  1. Pick a game that needs a specific round/clamp mode
  2. Set the needed round/clamp mode by manually editing the .opt file for the pcsx2 core
  3. Run the game; see if it works as intended

Also, does Close Content crash the core even before you get past the PlayStation logo? Try using Close Content during the bios/boot sequence, prior to when the logo appears. If that works, then you should be able to set core options that require content restart by setting those options before the logo appears, closing content, and loading the content again.

covey-j commented 3 years ago

So quite frankly, I'm just amazed at how badly the core was borked because of what Microsoft described as a simple "stability" update.

Honestly, it makes sense to me that a stability update would mess with this core. Close Content in this core on Xbox has been borked from the beginning. The issue just wasn't as noticeable before because of PR #56, which was always intended to be a temporary workaround for the issue. Even though it addressed most of the crashes, there was still that lingering zombie process. If I had to guess, the stability update that Microsoft pushed probably (and understandably) doesn't like the zombie process.

So my hypothesis on this is that if we can finally fix whatever threading issue is causing that zombie process, then Close Content would work again.

GABO1423 commented 3 years ago

But if the core crashes on Close Content, then the core options you choose won't get saved for the next boot. So I think the options themselves would work just fine if either Close Content or Restart Content were fixed.

True, but this can be worked around using the Flush Options to Disk setting RetroArch offers, which do save the core settings without needing to Close Content. Which is what I've been doing, and some settings do work correctly this way, liked switching the internal resolution, so why the Clamping/Round Mode settings do not work is beyond me.

I can't test this hypothesis myself for the foreseeable future (my friend is borrowing my Xbox until I finish my dissertation), but if you'd like test it, here's what you can do:

  1. Pick a game that needs a specific round/clamp mode
  2. Set the needed round/clamp mode by manually editing the .opt file for the pcsx2 core
  3. Run the game; see if it works as intended

Tried it manually just to be thorough, but nothing changed in Klonoa 2 (the game I'm using as an example).

Also, does Close Content crash the core even before you get past the PlayStation logo?

Yes, it doesn't matter when you use Close Content, it always crashes.

inactive123 commented 3 years ago

For one, they broke DXGIResizeBuffers in their dashboard updates -

https://twitter.com/flibitijibibo/status/1434020117113888771

https://github.com/FNA-XNA/FNA3D/commit/b490a9ba2b866a2e43fb58866b91e66715bdc13c

We suffered from the very same regression in RetroArch. @tunip3 had to make a patch to work around it.

So yeah, there have been regressions in their latest dashboard update.

GABO1423 commented 3 years ago

So quite frankly, I'm just amazed at how badly the core was borked because of what Microsoft described as a simple "stability" update.

Honestly, it makes sense to me that a stability update would mess with this core. Close Content in this core on Xbox has been borked from the beginning. The issue just wasn't as noticeable before because of PR #56, which was always intended to be a temporary workaround for the issue. Even though it addressed most of the crashes, there was still that lingering zombie process. If I had to guess, the stability update that Microsoft pushed probably (and understandably) doesn't like the zombie process.

With this in mind then yeah, I can also see where you are coming from. But what I don't get is why it would mess with the core in this specific way. In which it always crashes when trying to apply the game fixes from the GameDB, but when that is broken, the game boots up fine.

GABO1423 commented 3 years ago

For one, they broke DXGIResizeBuffers in their dashboard updates -

https://twitter.com/flibitijibibo/status/1434020117113888771

FNA-XNA/FNA3D@b490a9b

We suffered from the very same regression in RetroArch. @tunip3 had to make a patch to work around it.

So yeah, there have been regressions in their latest dashboard update.

Thanks for the information mate. Makes me understand this issue a lot better.

bslenul commented 3 years ago

uhm... I don't see nothing wrong, if not the initial:

[libretro INFO] Invalid BIOS file: scph39001.bin

anyway it seems that it has not effects, but not sure why this bios log appears here...

Yeah it happens on PC too, and for some reason if the filename is more than 11 characters (15 with the extension), the text is all weird:

[libretro INFO] Loading selected BIOS:  D:\programmes\RetroArch\system\pcsx2\bios\scph-12chars.bin
[INFO] [Environ]: SYSTEM_DIRECTORY: "D:\programmes\RetroArch\system".
[libretro INFO] Invalid BIOS file: 6l 

but fine if 11 characters or less:

[libretro INFO] Loading selected BIOS:  D:\programmes\RetroArch\system\pcsx2\bios\scph11chars.bin
[INFO] [Environ]: SYSTEM_DIRECTORY: "D:\programmes\RetroArch\system".
[libretro INFO] Invalid BIOS file: scph11chars.bin 

Not sure what's happening, but it doesn't seem to affect the games or anything.

edit: Fixed with #164 :)

GABO1423 commented 3 years ago

After some more experimentation, I made a build in which the GameIndex.yaml file contained no patches, instead just having the actual emulator settings (Like the Clamp/Round modes for instance), I then used xxd to generate a new GameIndex.h file from the yaml file for the build. But sadly, the core still crashed after the PlayStation 2 logo with Klonoa 2. So I suspect the Xbox is having an issue with applying the compatibility emulator settings instead of the pnach patches themselves.

Here's the core for those who are curious: pcsx2_libretro.zip

GABO1423 commented 3 years ago

Well, what Microsoft borke, they seemingly have fixed in their latest OS update. So this can now be closed. :)

On the latest Xbox update with the latest core from the buildbot, Burnout 3, Klonoa 2, and Crash Twinsanity all booted up correctly.

Gamr13 commented 3 years ago

After multiple tests on two separate consoles, I can confirm this issue is NOT resolved. This issue should be re-opened.

Gamr13 commented 2 years ago

Updating to the Xbox Insider Delta channel seems to have resolved both USB issues and PCSX2 as well.

Interestingly, @GABO1423 is not on the Xbox Insider builds. I'll keep a sharp eye out for any changes.