-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix video playback in LocoRoco 2. scePsmfPlayerGetInfo had a couple m…
…ore parameters. Fixes #7887.
- Loading branch information
Showing
1 changed file
with
29 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
e9d5eb6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes Growlanser hit invalid memory accesses.
I added this:
hleLogError(ME, 0, "TEST %08x %08x", psmfPlayerLibVersion, psmfplayer->playerVersion);
And see this:
00000000=scePsmfPlayerGetPsmfInfo(096645e0, 096645a8, 00000000, 09ba3a48): TEST 05050010 00000001
A few ideas:
a3 == a2 + 4
in LocoRoco 2?Can you share the values for LocoRoco 2?
-[Unknown]
e9d5eb6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might very well be right , it might only have 2 parameters. Here are the values in LocoRoco2:
psmfPlayer = 0x09fbf2ec
psmfInfoAddr = 0x09fff610
widthAddr = 0x09fff624
So it could very well be explained by psmfInfo having a few extra fields (possibly in this and later library versions) and widthAddr just happening to point to the size part of it.
e9d5eb6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never mind, that doesn't work because heightAddr is 0x09fbf3ac which is closer to psmfPlayer which seems unlikely to be part of the same structure? Or actually, it might be that the app computed the address in psmfPlayer from which to read the height before making the call, and it just happened to be in a parameter-looking register. Hm.
e9d5eb6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The following works, of course:
But in that case, if the value is just part of the psmfPlayer struct it probably has nothing to do with GetPsmfInfo, just an accident that it was reading it soon after - and we should do that memory write earlier, like when opening the video.
e9d5eb6
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. From memory, I think the
psmfPlayer
reference is a pointer to a struct - and currently we just have it point to itself (in case they copy that pointer.) So maybe it's reaching into that struct...I did a quick test against 03080010 and 05000010, and didn't reproduce either behavior:
However, it might be that the first field is treated as the struct size or something, I didn't spend much time trying things. I didn't have 03090510 to test against, but see a few games use that version:
http://report.ppsspp.org/logs/kind/589
-[Unknown]