hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.43k stars 2.19k forks source link

[Undub][USA] Mega-Man Powered Up - cannot pass menu/intro without pressing start. #15004

Open ghost opened 3 years ago

ghost commented 3 years ago

Game or games this happens in

ULUS10091

What area of the game / PPSSPP

After memory checking press circle the game stuck on blackscreen need to press start button twice to pass. Screenshot_2021-10-10-09-31-44

I try to report to ppsspp compatibility but I'm not the only one that experience this Screenshot_2021-10-10-09-32-24

What should happen

Adding this game to MpegAvcWarmUp fix the issue but skip the cut-scene.

Logs

logcat_10-10-2021_09-45-06.txt recording.ppdmp.zip

Platform

Android

Mobile phone model or graphics card

Cloudfone Excite Prime Android 5.1 Mali-450 GPU

PPSSPP version affected

v1.12.1-3

Last working version

No response

Graphics backend (3D API)

OpenGL / GLES

Checklist

Panderner commented 3 years ago

I cannot reproduce this issue for me: Screenshot (40)

FMV opening scenes after memory check screen is working fine for my PC and Android phone.

unknownbrackets commented 3 years ago

It seems like reporting says that you have function replacements disabled? That could cause unexpected issues.

-[Unknown]

ghost commented 3 years ago

I cannot reproduce this issue for me: Screenshot (40)

FMV opening scenes after memory check screen is working fine for my PC and Android phone.

Im using the usa undub edition Screenshot_2021-10-10-11-20-12-939_org ppsspp ppsspp

ghost commented 3 years ago

It seems like reporting says that you have function replacements disabled? That could cause unexpected issues.

-[Unknown]

I can also reproduce this on my redmi note 9

https://user-images.githubusercontent.com/37603562/136680476-89cba904-2f69-46d4-81be-eb4fed079f09.mp4

Panderner commented 3 years ago

I can reproduce this for undub version but not original USA version.

unknownbrackets commented 3 years ago

Did it work on previous PPSSPP versions? Is it possible this is a bug in the undub? Does it work on a PSP?

-[Unknown]

ghost commented 3 years ago

Did it work on previous PPSSPP versions?

No

Is it possible this is a bug in the undub? Does it work on a PSP?

-[Unknown]

Sorry idk :( I don't have psp console to confirmed this.

ghost commented 3 years ago

Temporary workaround

[MpegAvcWarmUp]
# Fix blackscreen issue but skip cuts-scene
# Mega-Man Powered Up
ULUS10091 = true
Panderner commented 3 years ago

Real hardware is needed since Gamemulatorer doesn't have a real hardware to test if is a bug for this patched game.

sum2012 commented 2 years ago

@unknownbrackets I am using Undub v1.2 Confirm in real PSP. The patch iso do not have problem EDIT:update ppsspp log without "IO" v1.13.1-544-g31bd16a04 log: https://gist.github.com/sum2012/01f149ce530d714ac2bb782ac9403e74

Real psp log: https://gist.github.com/sum2012/5cb86c33a1e507b5657c3027b8f33227

sum2012 commented 2 years ago

edit:updated ppsspp log with "IO"

Real psp log: 00:16.601 user_main - sceKernelCreateThread 0x08AF4014(''), 0x893A708, 118, 0x1000, 0x0, 0x0 = 0x4375F23 00:16.935 user_main - sceKernelCreateThread 0x08AF3FAC(''), 0x882C6A8, 116, 0x20000, 0x4000, 0x0 = 0x4363C3B 00:17.083 - sceMpegRingbufferQueryMemSize 0x640 = 0x348A00 00:17.105 - sceMpegRingbufferConstruct 0x9FB7C64, 0x640, 0x9B00000, 0x348A00, 0x892BC24, 0x8AF6578 = 0x0 00:17.153 - sceMpegCreate 0x9FB7C60, 0x95A0070, 0xB3DB, 0x9FB7C64, 0x200, 0x0 = 0x0 00:17.238 - sceKernelCreateThread 0x08A2115C('soundThread'), 0x892BCAC, 61, 0x800, 0x0, 0x0 = 0x4356227 00:17.254 - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x640 00:17.279 - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x640 = 0x20

unknownbrackets commented 2 years ago

This part is interesting. Here's the PPSSPP log:

50:05:987              D[ME]: HLE\sceMpeg.cpp:1471 1472=sceMpegRingbufferAvailableSize(09fbc964)
50:05:987              D[ME]: HLE\sceMpeg.cpp:1576 sceMpegRingbufferPut(09fbc964, 32, 1472)
50:05:988              D[ME]: HLE\sceMpeg.cpp:1538 packetAdded: 32 packetsRead: 160 packetsTotal: 1600
50:05:988              D[ME]: HLE\sceMpeg.cpp:1775 0=sceMpegGetAtracAu(09fbc960, 00000002, 09fbc9a8, 09fbc8c0)
50:05:988              D[ME]: HLE\sceMpeg.cpp:1983 sceMpegAtracDecode(09fbc960, 09fbc9a8, 097d4880, 0)
50:06:004              D[ME]: HLE\sceMpeg.cpp:1471 1440=sceMpegRingbufferAvailableSize(09fbc964)
50:06:004              D[ME]: HLE\sceMpeg.cpp:1576 sceMpegRingbufferPut(09fbc964, 32, 1440)
50:06:004              D[ME]: HLE\sceMpeg.cpp:1538 packetAdded: 32 packetsRead: 192 packetsTotal: 1600
50:06:004              D[ME]: HLE\sceMpeg.cpp:1775 0=sceMpegGetAtracAu(09fbc960, 00000002, 09fbc9a8, 09fbc8c0)
50:06:004              D[ME]: HLE\sceMpeg.cpp:1983 sceMpegAtracDecode(09fbc960, 09fbc9a8, 097d68c0, 0)
50:06:020              D[ME]: HLE\sceMpeg.cpp:1471 1408=sceMpegRingbufferAvailableSize(09fbc964)

But compare that to this in the PSP log:

00:17.744  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x5C0
00:17.765  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x5C0 = 0x20
00:17.786  - sceMpegGetAtracAu 0x9FB7C60, 0x95A1680, 0x09FB7CA8(0xFFFFFFFF), 0x09FB7BC0(0x95ADCC8) = 0x0
00:17.804  - sceMpegAtracDecode 0x9FB7C60, 0x09FB7CA8(0xFFFFFFFF), 0x097D4880(0x8D008D), 0x0 = 0x0
00:17.820  - sceMpegGetAvcAu 0x9FB7C60, 0x95A1280, 0x09FB7C90(0xFFFFFFFF), 0x09FB7BBC(0x1) = 0x0
00:17.839  - sceMpegAvcDecode 0x9FB7C60, 0x09FB7C90(0xFFFFFFFF), 0x200, 0x08AF65F4(0x9746650), 0x09FB7BB8(0x1) = 0x0
00:17.856  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x5A2
00:17.882  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x5A2 = 0x20
00:17.902  - sceMpegGetAtracAu 0x9FB7C60, 0x95A1680, 0x09FB7CA8(0xFFFFFFFF), 0x09FB7BC0(0x95ADCC8) = 0x0
00:17.920  - sceMpegAtracDecode 0x9FB7C60, 0x09FB7CA8(0xFFFFFFFF), 0x097D68C0(0xBA00B8), 0x0 = 0x0
00:17.936  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x582
00:17.952  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x582
00:17.976  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x582 = 0x20
00:17.992  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x562
00:18.013  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x562

1472 is 0x5C0, so that matches. But afterward, PPSSPP goes down to 1440 aka 0x5A0, which is the next step. However, the PSP goes to 0x5A2. After that, it keeps going down by 0x20, but it just ignores 2 of the put packets.

This reminds me of #8803 and #3318. We found that certain versions (but not all, importantly) of sceMpeg were rejecting invalid packets. I tried a corpus of mpeg libs from games I had access to, but maybe this undub is using a different version of sceMpeg that shares the invalid packet counting difference?

It says: Loading module sceMpeg_library with version 0104, devkit 00000000. That's higher than 0x0103, which was the last version I was aware of doing this manner of counting. See here:

https://github.com/hrydgard/ppsspp/blob/9f4a849453d7256ee55a0024ef11fa46c5095de3/Core/HLE/sceMpeg.cpp#L1184-L1190

Anyway, after a while the PSP does start returning an error because packets are garbage:

00:18.359  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x4A2
00:18.379  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x4A2 = 0x806101FE

Which PPSSPP is also correctly doing:

50:06:137              D[ME]: HLE\sceMpeg.cpp:1471 1184=sceMpegRingbufferAvailableSize(09fbc964)
50:06:137              D[ME]: HLE\sceMpeg.cpp:1576 sceMpegRingbufferPut(09fbc964, 32, 1184)
50:06:138              E[ME]: HLE\sceMpeg.cpp:1508 sceMpegRingbufferPut(): invalid mpeg data

This is at 0x4A0 instead of 0x4A2, though, because of the above noted discrepancy.

Despite that, as the PSP keeps taking invalid packets, it is decreasing the counts:

00:18.379  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x4A2 = 0x806101FE
00:18.396  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x482
00:18.418  - sceMpegRingbufferPut 0x9FB7C64, 0x20, 0x482 = 0x806101FE
00:18.433  - sceMpegRingbufferAvailableSize 0x9FB7C64 = 0x462

Which is something I found was not happening in 0x0104: https://github.com/hrydgard/ppsspp/blob/9f4a849453d7256ee55a0024ef11fa46c5095de3/Core/HLE/sceMpeg.cpp#L1511-L1515

I assume it would "work" (not as a fix) if we allowed this on 0x0104? Although that contradicts tests made on #8803 with other games using a lib at 0x104, which probably means there are different mpeg libraries with the version 0x104. What's a bit more interesting to me is - did the undub replace the mpeg library with a newer (hacked?) version? Or is it that only the undub has a corrupt mpeg? In other words, why does it work in PPSSPP without the undub?

Anyway, I guess this means we probably need to resort to a signature check for the mpeg library to determine its true version, Or something. First thing would be to confirm if changing these checks would help.

-[Unknown]

sum2012 commented 2 years ago

@unknownbrackets The above two changes from 103 to 104 don't work (or the bottom change only) Please check private message in http://forums.ppsspp.org

ghost commented 1 year ago

This is a game bug or what?

sum2012 commented 1 year ago

https://github.com/hrydgard/ppsspp/issues/15004#issuecomment-1229357967

I have tested the iso ,the real psp do not have problem

在 2022年12月31日週六 上午12:13,Gamemulatorer @.***> 寫道:

This is a game bug or what?

— Reply to this email directly, view it on GitHub https://github.com/hrydgard/ppsspp/issues/15004#issuecomment-1367990421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQTT7C6UOV7AECXSRDCNODWP4C35ANCNFSM5FV46TBQ . You are receiving this because you commented.Message ID: @.***>