Nothing too exciting in the log window though It always breaks no matter when do you apply the workaround, but it does so always at one particular place.Īnyway, 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. The minigame is about pressing the right buttons at the right times. There is minigame of "Party boy", and as I mentioned in my post, it is not playable and requires cheating. I think I found yet another interesting detail, but it requires a bit of context, 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). If you change the CPU clock (under System settings) to 100 or 400, does it change any of this behavior? game crashing if tried to exit minigame after timers glitch out.Always the same line, with the same value and (I suppose) address 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. (Possibly) other stunts of the similar nature may make use of this workaround as well if need beĢ8:09:361 FMOD Streame E: hle\sceatrac.cpp:570 avcodec_decode_audio4: Error decoding audio -1094995529 / bebbb1b7 After finishing stunt, save game and forget about stunt thereafter.While the stunt running, Wait another 10 seconds, perform workaround.With a RAM hacking software, set the score to >750 to pass it.Reason is simple: The music, and timers accordingly, reset entirely upon stunt restarting Tick, then reset: Nothing changes Unsolved issues While testing, the parameter is Disabled (unchecked). Make sure you're not using "real time clock sync" While the stunt running, perform workaroundĪka Game Settings -> More settings -> System -> Emulation -> Force real clock sync (slower, less lag).(Recommended) set the emulation speed to, say, 20%.The second-best strategy, is not as stable, but useful where early stunt exiting is impossible is In the after-stunt menu, perform the workaround.Begin stunt, wait until the timers break.It seems there is a pattern, which is that, Found bypassable and non-Bypassable states are: Possibly wait ~5 seconds keeping the game runningīypassable state is the state in which the workaround may work out.Get the game to the specific "bypassable" state (explained below).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). If you try exiting before the timers break, you should be able to do so. All the music, gameplay, and moves begin looping incorrectlyĪnother side effect is, if you now "exit stunt", the game crashes entirely. Play it for 10 seconds (whether doing the moves or not), and notice the game's in-game timer looping incorrectly breaking the gameplay. The set-up I test, if I go to Minigames -> Golf Rally. Changed the same settings as for 1.7.4 -> seemingly the same in-game behaviour.Tried running again, the problem disappeared not sure why.The first time tried, for whatever reason the framerate wasn't capped.Rendering mode (required): Buffered rendering (unbuffered fails on minigames) Unplayableĭirect3D 11: no buffered parts rendered. (changed controls, shouldn't affect anything)ĭirect3D 9: colour glitches, texture glitches, image upside down. Seemingly the most stable version for this game: 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 himself) ROM Related (though different region, and issue is not necessarily game-specific): #11586
0 Comments
Leave a Reply. |