Absolum (PPSA28311)

[JJenkx]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

Absolum (PPSA28311)

Content version tested

01.002.000, from sce_sys/param.json.

AnyPS5 commit

Main 2626e5ee7e57df6e952a93a997a8b9fc79d80c08, compared with the same base plus the single commit from #7105 (c5da8f2f947d820035eba30d6f78e5c8c9fcde87). The patch is by Pouare514; this report adds Linux title testing of it. No other source changes were included in the candidate.

System tested

Arch Linux, Ryzen 9 7950X, Radeon RX 6650 XT (RADV NAVI23), Mesa/vulkan-radeon 26.2.4-1, GCC 16.2.1. Release build.

Furthest point

Menu — title screen and licence prompt, with #7105 applied. Gameplay has not been tested.

What is shown

On main, startup reaches the video-logo cleanup and aborts after approximately 40 seconds (exit 134).

With #7105 applied, a native run reaches the readable Absolum title screen with “Press Any Button.” A separate input run confirms that Cross opens a readable End User Licence Agreement prompt. That run remained open for approximately 198 seconds and exited normally after an ordinary window-close request (exit 0). The agreement was left unaccepted, so no claim is made about the main menu beyond this prompt, character selection, or gameplay.

The window reported approximately 59.9 FPS at the title/licence screens. This is only the displayed startup-screen rate, not a gameplay benchmark or a demonstrated performance gain. Audio correctness was not evaluated. Vulkan validation was not enabled for these native runs.

Current blocker

Main aborts with:

[Video] Disposing of video logos
terminate called after throwing an instance of 'std::invalid_argument'
  what():  direct memory range 0x2b1ef0000+0x2f8000 references unallocated physical page 0x2b1ef0000

Related implementation: #7105, which returns EACCES on unknown direct-memory release ranges. With that patch, startup passes this failure point. This observation does not establish that every memory-release path or later scene works.

The four focused Linux checks guest_memory_pool_stats, MemoryPoolTest, guest_memory, and guest_mmap_fixed_anonymous all passed on the candidate.

How it was run

Build libs and relinker from the pinned main, then repeat libs with the single #7105 commit applied. Conversion used the main relinker for both runs. From the extracted module directory:

/path/to/build-full/core/relinker/relinker --registry --module-dir . unused-filter=0 --rpath /path/to/build-full/core/libs/libs /path/to/eboot.elf /path/to/runtime/app.elf

The runtime has access to the extracted title assets. Launch from the runtime directory with:

LD_LIBRARY_PATH=/path/to/build-full/core/libs/libs SDL_VIDEODRIVER=x11 VK_DRIVER_FILES=/usr/share/vulkan/icd.d/radeon_icd.json APS5_HOST_IMPORT_MIB=16384 APS5_DRAW_CACHE_ENTRIES=4096 APS5_PIPELINED_DRAWS=0 ANYPS5_SHADER_CACHE_DIR=/path/to/separate-title-cache MESA_SHADER_CACHE_DIR=/path/to/mesa-cache ./app.elf

The test temporarily used an 8192 MiB udmabuf size limit and restored its previous 64 MiB limit after each run. Main and candidate startup runs used separate title shader-cache directories; the subsequent input run reused the candidate cache. These are functional startup comparisons, not matched performance measurements. No core dumps were retained.

AI-assisted testing and report preparation: yes.