New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Metal Gear Peace Walker (Android #12447) broken by async I/O change (was Burnout Dominator) #12549
Comments
Comments are comments, whether they issue is marked as fixed or not. They always count. Me and Henrik (and a few hundred other people) get an email for every issue or comment you create. A log would help, since I don't have this game. -[Unknown] |
Hmm I don't see any crashes but it's seems the game is playable |
@Panderner Are you really testing the latest build from https://buildbot.orphis.net/ppsspp/ ? It broke recently, it seems. |
Yes. It's v1.9.3-189-g6d8ddb7a7 |
@JBDaz what android phone are you using? |
My current phone is an OP7TPro ... |
@JBDaz have you tried to update the latest build? |
Most likely this was fixed by v1.9.3-171-g347433910. It would not be platform specific. -[Unknown] |
MGS:PW with v1.9.3 build 189 still freeze after logo Konami. [Android/Windows] 😂 |
I can confirm that metal gear peace walker keeps crashing on the latest versions on my honor 9 lite. The last working one was v1.9.3-167-gb2dd3c7e1 as stated above. Right now I'm very busy, but next week I think I'll be able to drop a log here if needed 😃 |
Metal Gear PW seems to be the game with the problem now indeed, so renaming the issue. |
Bisected, and the breaking commit is 593e48b . Strange. |
Hm, a log might help. I'm most interested in: What SDK ver does the game use? -[Unknown] |
Log up until the crash: It doesn't call sceIoChangeAsyncPriority. Lots of module loading and linking though. I can do more checks tomorrow. |
Module SDK: 05050010
Hm, seems like it either somehow failed to wake the kfs io0 thread, or something went wrong there. I guess it must somehow be related to the fake thread changes. Would be interesting to know how the SceIoAsync thread (there may be multiple, but the log looks like it should only have one) ends up, and if the kfs io0 thread is waiting still or something else. Otherwise I guess it'd somehow be an issue waking the thread here? Line 427 in 593e48b
-[Unknown] |
OK so it turns out the game at least starts up with I/O timing method = Simulate UMD Timing. We could force it on for this game, I suppose, but it still seems worrying that it's this unstable. It crashes pretty soon after the fourth time it reaches Turns out my log was missing the end because the log thread stopped running when the main thread crashed. Could get more log by pressing Run in VS, one half line at a time, but instead added a sleep statement so I could get it all. This is how it ends, although it just looks like more of the same:
|
Does it help if you change the -[Unknown] |
Yup, that makes it work. I guess CLOSE shouldn't have a delay indeed. Thanks! |
I think that's all of the reported regressions from the async changes... let's see if there are more. Or hopefully the opposite, maybe something started working :) |
I'm hoping for positive timing impacts, I think next step would be to adjust timing and scale to throughput a bit. There could be a lingering complexity of like serializing disc reads from separate threads (from a timing perspective), but hopefully that's not a common problem. -[Unknown] |
It WAS fixed up to v1.9.3-164-g0a5ec4838; BO Dominator works.
Recent async i/o changes (as of v1.9.3-170-g6a196c04a) broke it again - Burnout Dominator crashes again like seen in old issue.
(not sure if comments to closed issue count ? That's why I opened this as a "new" issue ...
The text was updated successfully, but these errors were encountered: