BloodRayne: ReVamped (PPSA05916)

[JJenkx]

Tested BloodRayne: ReVamped (PPSA05916) 01.001.000 natively on Linux 7.2.9 / Ryzen 9 7950X / Radeon RX 6650 XT, RADV Mesa 26.2.4. A Unity (IL2CPP) shell around the original engine in Media/Plugins/Rayne1.prx. Short bring-up check.

Result

On plain main 61d0fa5b3c the title boots without a driver stop and presents at a steady 59.94 FPS for 240 s, but every frame is black and it never progresses. The same happens with Cross, Options, touchpad, Square, Triangle, Circle and R2 presses.

What it does:

• Unity loads boot.config, global-metadata.dat, globalgamemanagers, sharedassets0 and level0 (all 22 APR reads complete, APS5_TRACE_APR=1).
• It loads SaveData.prx, PSNCore.prx, PSNCommon.prx and Rayne1.prx with sceKernelLoadStartModule.
• It then reads Media/Resources/mscorlib.dll-resources.dat (IL2CPP looks up a managed exception message there) and opens nothing else.
• strace (-e trace=%file) shows no access at all to Media/data/*.POD (6.8 GB of game data) in 80 s. The engine plugin, which imports only libc, stat and two sceRtc calls, is never asked for data.
• --trace-imports with APS5_TRACE_CALLS: the loop polls scePadRead, sceMouseRead, sceUserServiceGetEvent, sceImeUpdate and sceSystemServiceGetStatus, and submits about 3 draws per frame.
• All 9 sceKernelDlsym lookups that fail are Unity's optional native-plugin hooks (UnityPluginLoad, UnityRenderEvent and so on).

PPSA05975 (BloodRayne 2: ReVamped) behaves the same way, so the cause is likely common to both.

Setup

relinker --registry --rpath <build>/core/libs/libs --module-dir Media/Modules --module-dir Media/Plugins eboot.elf app.elf

Not found yet: which managed exception is raised, or what the shell waits for. Guest frames could not be unwound under gdb.

AI-assisted testing and report: yes, Claude Code.

[JJenkx]

Correction to the note above. A breakpoint on the title's own __cxa_throw (its sce_module/libc.prx export vkuuLfhnSZI#guest, offset 0x17060) records no C++ or managed exception in the first 90 s on main 5b59fbc553. So the mscorlib.dll-resources.dat read is not an exception being raised, and the stall has another cause. The method is described in #8786.

[JJenkx]

A RenderDoc capture of a frame at about 60 s (main 5b59fbc553) shows the black screen is not a rendering fault: the title submits only a depth-only fullscreen draw into a 1920x1080 D32S8 target and the present blit, and the presented image is black. The game is simply not drawing any content yet, which fits the engine plugin never being started.

[JJenkx]

Further narrowing on main 5b59fbc553 (state at about 60 s, all threads symbolized through the IL2CPP code-gen tables and global-metadata.dat):

• 11 Unity.PSN.PS5.Aysnc.WorkerThread::RunProc workers, the Unity.SaveData.PS5.Core Notifications, DispatchQueue and ProcessQueue threads, and a socket thread all idle in WaitHandle::WaitOneNative. No thread is blocked inside a C# method otherwise; the main thread only runs the player loop.
• No managed exception is thrown, and the only NP call is one sceNpGetAccountIdA. With fix(np): expose a local account ID while offline #6990 (local account ID while offline) composed, nothing changes.
• sceUserServiceGetEvent already returns the initial-user login event once.
• The metadata includes a Gemini.UserManagement.EngagementScreen.PS5 type, so the title probably waits on its engagement (press-to-start) screen. That screen is not drawn (the frame is one depth-only draw), and Cross, Options, touchpad, Square, Triangle, Circle and R2 presses do not advance it.

[JJenkx]

Root cause of the black screen, from the Windows side (RX 6700 XT, libraries from main 6c12024; IL2CPP code dumped with Il2CppDumper 6.7.46 from Media/Modules/Il2CppUserAssemblies.prx and global-metadata.dat; gdb breakpoints on the method addresses below).

The title is not on its engagement screen. EngagementScreen.PS5.UserIsEngaged and CheckForGamepadInputs are never called. It is stuck in Gemini.UserManagement.PS5.SingleUserManager.ProcessState (VA 0x19d840), which runs every frame and returns 0:

• Frame 1: user.IsRegistered (User +0x15) is false, so it calls SetUser(initialUserId). User.RegisterUser (0x19d6e0) sets isPending (User +0x14) and starts an asynchronous Unity.PSN UserSystem.AddUserRequest (Users.AddUser, 0x1a11b0, ContinueWith).
• Still in the same call, while StartupImage.isHidden is false, it calls StartupImage.Hide, then UDS.Start and the engagement screen, only if isPending is still set. Otherwise it returns.
• The request's completion User.OnRegisterUserRequestComplete (0x1a1360) runs on the User System PSN worker thread. It sets IsRegistered = success, clears isPending and calls OnUserIsRegistered. Here it finishes before the main thread reaches that check: OnUserIsRegistered is hit before SetUser returns. So isPending is already false, the startup image is never hidden, and every later frame takes the same "not pending" return. ProcessState is the only caller of StartupImage.Hide and UDS.Start in the module.

Check: setting isPending back to 1 in gdb before the second ProcessState call (diagnostic only) makes the title call StartupImage.Hide, UDS.Start and then UserIsEngaged every frame. The engine then starts reading data (Media/data/PCVOX.POD, art/menu_background_ingame_revamped.tif, video/ziggurat.mp4, logos.mp4, intro.mp4), where unpatched runs stop after mscorlib.dll-resources.dat. That read is a Mono collation-table load from CompareInfo.Compare in the Input System's device matching, not an exception.

So the title relies on the PSN add-user request taking longer than the rest of that ProcessState call. On the console it goes through system services; here the NP/UDS calls behind it return at once. I have not found which call the console spends that time in, and adding a delay to a library would be a timing hack, so there is no fix in this comment. BloodRayne 2 (#8765) has the same Gemini user-management code.

AI-assisted: yes (Claude Code)

[JJenkx]

Narrowed further: these are the system library calls the add-user request makes, from main 6c12024 libraries on Windows. The method was gdb breakpoints on every sce* export of libSceNp* and libSceUserService, logged between User.RegisterUser and User.OnRegisterUserRequestComplete.

44.942 GUEST SUM.ProcessState #1                     main thread
44.944 GUEST User.RegisterUser #1                    main thread
44.946 GUEST Users.AddUser #1                        main thread
44.948 sceNpWebApi2CreateUserContext                 "User System" PSN worker
44.949 sceNpGetAccountIdA                            "User System"
44.949 sceNpUniversalDataSystemCreateContext         "User System"
44.950 sceNpUniversalDataSystemCreateHandle          "User System"
44.951 sceNpUniversalDataSystemRegisterContext       "User System"
44.952 sceNpTrophy2CreateContext                     "User System"
44.952 sceNpTrophy2CreateHandle                      "User System"
44.954 sceNpTrophy2RegisterContext                   "User System"
44.954 GUEST User.OnRegisterUserRequestComplete      "User System"
44.965 GUEST SUM.OnUserIsRegistered                  "User System"
44.967 GUEST SUM.ProcessState #2                     main thread

The whole request takes about 6 ms here, and it completes while ProcessState #1 is still running on the main thread. The calls in it that do real work on a console are sceNpUniversalDataSystemRegisterContext and sceNpTrophy2RegisterContext, which register with the system's UDS and trophy services, and they return at once here. Either taking measurable time on hardware would be enough for this title. I have no console timing for them, so I am not proposing a library delay. A console measurement of those two calls would settle whether an implementation should be asynchronous or slower. BloodRayne 2 (#8765) runs the same code.

Evidence (local): evidence/PPSA05916/run21-npcalls (gdb.out), script runtime/PPSA05916/work/npcalls.gdb.

AI-assisted: yes (Claude Code)