Resistance Retribution - Ad Hoc

[TigasZ8]

Game or games this happens in

Resistance Retribution

What area of the game / PPSSPP

Hello, good afternoon, previously the Resistance Retribution game worked online, unstable at times, but it worked, in Ad-Hoc mode only, now with the new version of the PPSSPP emulator, even Ad-Hoc is no longer working.

What should happen

The Resistance Retribution game should continue to operate online, now with perhaps even better updates, even if it is just maintaining the Ad-Hoc mode, as it used to work in previous updates, now with the new version of the PPSSPP emulator, it could work and stabilize the Ad-Hoc, or even open the door for infrastructure to work that is so desired, I hope the situation is reversed, and thank you.

Logs

No response

Platform

Android

Mobile device model or graphics card (GPU)

Nokia

PPSSPP version affected

v1.17-109-g6e676b9d1

Last working version

v1.16.6-590-gb09e5f4d8

Graphics backend (3D API)

Vulkan

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try without any cheats and without loading any save states.
• [X] Include logs or screenshots of issue.

[TigasZ8]

Other situations of Resistance Retribution:

PSP to PS2/PS3 connectivity emulation (via pcsx2/rpcs3) Source: https://github.com/hrydgard/ppsspp/issues/13098

Infrastructure/online support Source: https://github.com/hrydgard/ppsspp/issues/14256

Resistance Retribution online Source: https://github.com/hrydgard/ppsspp/issues/14316

Resistance Retribution - Infected mode Source: https://github.com/hrydgard/ppsspp/issues/18361

[hrydgard]

@anr2me any idea what changes we've made to adhoc since 1.16.6? I can't think of anything major..

Some "git log" use finds c6628ee55c317e041117893d82e1a1f91785f482 and really not much else.. well there's also the "cleanup" commit af412817617ea3175a97500beab21118c95f234f which I had to partially back out.

[hrydgard]

Oh last working was 590, that implies #18560, which is highly surprising.

[hrydgard]

The symptom when it doesn't work is that the AdHoc menu crashes - and yes, confirmed that reverting the last commit from #18560, e1eecb475a89d9b4a05bf71fcb56354018a6e4e7 , does "fix" it.

@unknownbrackets fyi, i'm thinking of reverting it for 1.17.1, or disabling it for this game, but will look through it a couple more times first.

[hrydgard]

Actually come to think of it, it's likely a weird threading interaction, and not really the fault of #18560. We don't get the adhoc stuff very close to correct.. So, could even do something as weird as disabling memcpy slicing when in adhoc mode...

[anr2me]

I'm not sure what the slicing mean, does the sliced memset/memcpy triggers a thread's context switch? since switching threads could affects the timing if the game relies on it (ie. waking up a thread too early when all the data it supposed to use wasn't ready)

[unknownbrackets]

Yes, but more correctly. The old implementation before that change would block a thread for potentially a long time.

Example, PPSSPP old behavior:

Thread1 at 0.0: memset(blah, 0, 2MB); Thread1 at 56.0: BLOCK EMULATION FOR 56ms (3.5 frames) <-- OOPS Thread2 at 56.0: Finally runs (should've run 55ms ago) <-- OOPS

Same, but PSP behavior and new PPSSPP behavior:

Thread1 at 0.0: memset(blah, 0, 2MB); Thread1 at 0.9: BLOCK EMULATION FOR ~0.9ms (5% of a frame) Thread2 at 1.0: Runs at the expected time Thread1 at 1.2: BLOCK EMULATION FOR ~0.9ms (5% of a frame) ... Thread1 at 56.2: memset is finished.

Note that this is only a bug in how "replacements" work. If you disabled replacements and had the original memset MIPS code run via jit or interpreter, it would also reschedule to other threads instead of making the memset lock everything up for the entire time (it would be slightly more accurate and wake threads maybe a bit earlier.)

The interpreter/jit behavior is basically how the PSP behaves. So the bug here seems likely to be something else not timing right, maybe an adhoc callback firing unrealistically early, etc.

-[Unknown]

[anr2me]

Based on the Debug logs, there are no SCENET appeared nearby the crash, since it happened early when selecting ADHOC menu, SCENET activity practically done after Network Initialized message, then the game do SavedataInitStart dialog and crashed before Savedata completed (i think it didn't even reached dialog status = 1 yet).

And the only thing AdhocThread did at this point is just looping the sceKernelDelayThread(10000) on the fake HLE (_NetTriggerCallbacks), as there are no more event that can be processed, thus no callbacks.

Debug logs without SCEKERNEL & SCEINTC:

Debug logs without SCEKERNEL, SCEINTC, ME, SCEAUDIO:

[hrydgard]

Worked around temporarily by #18821 , tagging any more proper fixes for v1.18

[NirYeF]

Worked around temporarily by #18821 , tagging any more proper fixes for v1.18

@hrydgard also happens with every Syphon Filter game almost as they share the same engine with Resistance. Happens with Combat Ops I think it gonna happen with Logan's Shadow as well.