Save State -> Load state changes in-game mechanics in "Jackass: the Game"

[TAbdiukov]

related (though different region, and issue is not necessarily game-specific): #11586

I want to clarify that while the problem is rare, the emulator behaviour (which is what I want to concentrate the issue on) is still very weird (as confirmed by @hrydgard himself)

ROM

Jackass the Game (Europe).iso

Size: 1,812,494,336 bytes CRC32: FB133420 MD5: 3A714CB9A2BCF79DB7203273DC5EECC0 SHA1: d03293698b7b112d7c6e010190f97043e32912b0 SHA384: 9c09d296db959ca53b75e8dc70a3155685d7e6514a1bbff1130d27d886a60877a6aeeb49f652dfaf58df0302d3775303

PPSSPP

PPSSPP 1.7.4; settings changed

Seemingly the most stable version for this game:

• (changed controls, shouldn't affect anything)

• Rendering backend: Direct3D 9: colour glitches, texture glitches, image upside down. Unplayable Direct3D 11: no buffered parts rendered. Unplayable OpenGL: best rendering backend in avail Vulnano: (unable to test out)

• Rendering mode (required): Buffered rendering (unbuffered fails on minigames)

PPSSPP 1.8.0;

• The first time tried, for whatever reason the framerate wasn't capped. Not sure why.
• Tried running again, the problem disappeared; not sure why
• Changed the same settings as for 1.7.4 -> seemingly the same in-game behaviour

Now to the game itself.

• The set-up I test, if I go to Minigames -> Golf Rally. Play it for 10 seconds (whether doing the moves or not), and notice the game's in-game timer looping incorrectly breaking the gameplay. All the music, gameplay, and moves begin looping incorrectly

• Another side effect is, if you now "exit stunt", the game crashes entirely. If you try exiting before the timers break, you should be able to do so.

"Weird workaround"

As I described,

if you PAUSE the emulation and then resume it, the game kinda rolls out its wheels and stops glitching (including that it allows to exit minigames). How is it even possible?

Turns out I slightly misremembered it. What you really need to do, is go to is,

1. Get the game to the specific "bypassable" state (explained below)
2. Save state
3. Load state
4. If did not work out
   • Possibly wait ~5 seconds keeping the game running
   • Go to 2

Bypassable state

Bypassable state is the state in which the workaround may work out. Found bypassable and non-Bypassable states are:

Non-bypassable

• Pause menu

Bypassable

• "Action", i.e. while the stunt running

  ---

• "Injury report" - i.e. score obtained
• "Video footage obtained", i.e. achievements
• End stunt menu

---

---

TL:DR

it seems there is a pattern, which is that,

• Music plays -> Bypassable
• Music does not play -> Non-bypassable

Strategy

1. Best strategy is,

   • Begin stunt, wait until the timers break
   • Fail it
   • In the after-stunt menu, perform the workaround

2. The second-best strategy, is not as stable, but useful where early stunt exiting is impossible is

   • Begin stunt, wait until the timers break
   • (Recommended) set the emulation speed to, say, 20%
   • While the stunt running, perform workaround

real time clock sync

aka Game Settings -> More settings -> System -> Emulation -> Force real clock sync (slower, less lag)

make sure you're not using "real time clock sync"

While testing, the parameter is Disabled (unchecked).

Try with it on (just to test out): Tick, then reset: Nothing changes

Unsolved issues

1. Party boy is still unplayable. Reason is simple: The music, and timers accordingly, reset entirely upon stunt restarting Workaround:
   1. Begin stunt, wait until the timers break
   2. With a RAM hacking software, set the score to >750 to pass it
   3. While the stunt running, Wait another 10 seconds, perform workaround
   4. If failed, goto 3
   5. After finishing stunt, save game and forget about stunt thereafter

(Possibly) other stunts of the similar nature may make use of this workaround as well if need be

[unknownbrackets]

Can you try the latest git build?

It's possible some of the scePower changes (since v1.8.0) could have some impact to this. But also, there was a bug (I thought it was fixed in v1.8.0, but maybe only in git builds) where loading state and resetting emulation would not update the cpu clock properly.

If you show the log console (Debug -> Log Console), does it show any red or yellow messages? Especially when loading or saving state?

If you change the CPU clock (under System settings) to 100 or 400, does it change any of this behavior?

-[Unknown]

[TAbdiukov]

Thanks [Unknown] for your response!

Can you try the latest git build?

It's possible some of the scePower changes (since v1.8.0) could have some impact to this. But also, >there was a bug (I thought it was fixed in v1.8.0, but maybe only in git builds) where loading state >and resetting emulation would not update the cpu clock properly.

Sure. Do I need to download the latest state of repo, or the latest release (under releases)?

I will need to download compiling tools and other things, but I will get you know once I get the results.

Also, if this is of any help, I believe the problem dates back to PPSSPP 0.7 era, and I think I remember even back then doing something similar

If you show the log console (Debug -> Log Console), does it show any red or yellow messages? Especially when loading or saving state?

Heh, aplenty. And all in red.

Both 1.7.4 and 1.8.0: When starting the game (to the main menu), it prints,

25:44:894 VideoThread  E[ME]: hle\scepsmf.cpp:1516 scePsmfPlayerUpdate(09601b20): not playing yet
25:44:894 VideoThread  E[ME]: hle\scepsmf.cpp:1567 scePsmfPlayerGetVideoData(09601b20, 09fcdaa0): psmf not playing
25:44:894 AudioThread  E[ME]: hle\scepsmf.cpp:1660 scePsmfPlayerGetAudioData(09601b20, 09903bc0): not yet playing

1.8.0 only: Right before timers glitch out,

44:41:723 FMOD Streame E[ME]: hle\sceatrac.cpp:565 Unsupported feature in ATRAC audio.

Both 1.7.4 and 1.8.0: After the timers glitch out, one or tons of these,

28:09:361 FMOD Streame E[ME]: hle\sceatrac.cpp:570 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7

Interestingly, if I try workaround (described in the first post), and it doesn't work out (which is kinda like the old PSP 3000 TIFF jailbreak - it only works when feels like it), the error gets re-printed. Always the same line, with the same value and (I suppose) address

Strangely enough, no error messages on:

• when loading or saving state
• when workaround successful
• game crashing if tried to exit minigame after timers glitch out

If you change the CPU clock (under System settings) to 100 or 400, does it change any of this behavior?

Not for values about 100 or 400. The video gets either too slow or too fast (too smooth), but the gameplay does not seem to be affected (including the in-game timers). I think I found yet another interesting detail, but it requires a bit of context,

There is minigame of "Party boy", and as I mentioned in my post, it is not playable and requires cheating. The minigame is about pressing the right buttons at the right times. It always breaks no matter when do you apply the workaround, but it does so always at one particular place.

Anyway, I tried to lower the CPU clock down to the extreme values (~12 MHz) and tried the workaround, and to my own surprise, after I loaded the state the "dancing timeline" slighly progressed off the place it breaks on usually. Not sure what to make out of this. Nothing too exciting in the log window though

[unknownbrackets]

Sure. Do I need to download the latest state of repo, or the latest release (under releases)?

The easiest way is to just download the latest build from here: https://buildbot.orphis.net/ppsspp/

If you want to compile it, you mostly only need Visual Studio 2019 Community, and I'd suggest using a recursive git clone. Otherwise, it's designed to be easy to compile without lots of dependencies or hardcoded paths.

That said, I think the prebuilt binaries should work fine. But based on your other answers, I suspect the latest git build won't help after all.

Unsupported feature in ATRAC audio.

Interesting. This might mean an Atrac 3+ buffer issue or stream error, most likely. In theory, save state / load state should not change the behavior of that, but this might point toward the bug. We do have to reload data into ffmpeg on load state.

Always the same line, with the same value and (I suppose) address

It does look like an address, but 0xbebbb1b7 is actually FFmpeg's AVERROR_INVALIDDATA constant.

We probably don't return correct-looking data to the game when a packet fails to process through FFmpeg, and the game freaks out.

Does "Party boy" also show this error message when things go wrong?

-[Unknown]

[TAbdiukov]

@unknownbrackets Again, thanks for your interest. Couldn't respond earlier because life.

The easiest way is to just download the latest build from here: https://buildbot.orphis.net/ppsspp/

Oh cool! I thought I'd need to build on my own. I downloaded and ran the latest build, same behaviour as in the official 1.8.0 release :(

This might mean an Atrac 3+ buffer issue or stream error, most likely

AND

Does "Party boy" also show this error message when things go wrong?

Yes, in "Party boy" there is the same message showing up.

I appreciate trying to pinpoint issue, but I think I made the things less clear. Sorry if I repeat myself below.

In its core, the issue appears to be that after ~10 seconds of playing any of the mini-games, the majority of in-game timers break. The 'symptoms' of timers breaking are,

• Trying to exit minigames results in game crash
• The last ~0.5 of seconds of music loop infinitely
• (Possibly gameplay is also affected, but I don't know for sure.)

So the music breaking up is just one of (possibly) many things breaking.

"Party boy" demonstrates the same behaviour. In most if not in all (except from 'party boy') games, if I do the workaround, the timers seem to return to normal.

But unlike other minigames, in "Party boy", if I do the workaround and it works, the minigame finishes, and so to pass "Party boy", one'd need to use cheats to change in-game score. Also, unlike in other minigames, the background music resets if minigame resets, which might help find out the root cause of the problem. I think it might be because "Party boy" gameplay mechanics depend on background music, and which is why it is different

[TAbdiukov]

You know, it's been a while, and if I can be of any further help, feel free to ask!

[Panderner]

Any minigames runs very slow it rans at 5 FPS on Realme C2.

[Panderner]

Party Boy getting stuck this part: Screenrecorder-2020-12-16-14-00-10-258.mp4.zip

[Panderner]

and here's a log where party boy stucks this part:

FMOD Streame E[ME]: HLE/sceAtrac.cpp:571 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7

[TAbdiukov]

@Panderner Don't use Direct3D 11 or OpenGL. Use Vulkan or Direct3D 9

@benderscruffy

Is this still an issue??

PPSSPP 1.16.6

I can confirm that the issue is still present, HOWEVER something is changed, and the game can progress without Save State -> Load State trick.

I think old bugs may have been fixed, and new bugs were introduced

However, the music is looped incorrectly, as it constantly restarts from the beginning. Previously, it would get stuck in ~2second loop toward where the game would get stuck. So,