rcheevos: add initial RetroAchievements integration

[Alasonga]

Summary

Adds initial RetroAchievements integration to RPCS3 using the rcheevos library. This is a foundational implementation that establishes the full client pipeline: login, game identification via hash, frame-by-frame memory processing, and session management.

What's included

• rcheevos added as a git submodule under 3rdparty/
• rc_client integration with async HTTP via libcurl (already a RPCS3 dependency)
• Memory reader hooked into vm::g_base_addr for PS3 RAM access
• Game identification via EBOOT.BIN hash sent to the RetroAchievements server
• Login with username/password, token persistence via ra.yml
• New settings window accessible from: Manage > RetroAchievements
• Hooks in RSXThread::on_frame_end(), Emulator::Init(), Emulator::Run(), and Emulator::Kill()
• RPCS3_RA_ENABLED compile-time flag (off by default) to avoid any impact on standard builds

Current status

The integration is functional end-to-end on Windows. Login, hashing, and server communication work correctly. The server returns "Unknown game" because PS3 is not yet a supported platform on RetroAchievements. This PR establishes the emulator side of the integration ahead of that support being added.

Tested on

• Windows 11, Visual Studio 2026, CMake 4.4.2
• Demon's Souls (BLUS30443) - hash generated and submitted to RA server successfully

[Alasonga]

Note: AI tools were used to assist in development. All code was reviewed, tested, and verified manually before submission.

[AniLeo]

Is the RetroAchivements team fine with this? RA guidelines forbid uploading official trophy sets. Are they going to come up with completely different achivements for games that were already designed with them in the first place?

[Valtekken]

Is the RetroAchivements team fine with this? RA guidelines forbid uploading official trophy sets. Are they going to come up with completely different achivements for games that were already designed with them in the first place?

That's probably what's gonna happen considering their policy

[Alasonga]

Is the RetroAchivements team fine with this? RA guidelines forbid uploading official trophy sets. Are they going to come up with completely different achivements for games that were already designed with them in the first place?

I haven't talked to them yet but this PR exists to give the RA team a concrete foundation when I approach them about adding PS3 support, rather than arriving with just a proposal. So, yes, PS3 achievement sets would be created from scratch by the community.

I'll just wait a little to see if any problems emerge, code side and with the RPCS3 side

[AniLeo]

I believe we're going to wait on an official response from the RA team on whether they are open to adding PS3 support or not before merging this

[wescopeland]

Hi!

RetroAchievements admin here 👋

Thanks for your work on this PR so far! We've discussed PS3 support internally and generally are in favor of supporting PS3 achievement sets on RetroAchievements. One thing to state up front: even if the integration were 100% complete today, we couldn't give a firm go-live date for a rollout. This would probably be anywhere from 6-12 months out of integration completion date.

Setting that aside, we have a few finer technical points that need to be addressed.

1. RPCS3 needs toolkit support.
At the moment, this PR only integrates rc_client. For achievement developers to build achievement sets, they need to use RAIntegration (rc_client_raintegration). See: https://github.com/RetroAchievements/rcheevos/wiki/rc_client_raintegration

2. PS3 needs a dedicated console ID.
rcheevos needs a RC_CONSOLE_PLAYSTATION_3 value. This needs to land as a PR in rcheevos itself.

3. PS3 needs a memory map.
Each system we support must have a memory map in consoleinfo.c. See: RetroAchievements/rcheevos#520 RetroAchievements/rcheevos#515 RetroAchievements/rcheevos#446 RetroAchievements/rcheevos#472

Please read PR 446's discussion before attempting to write a PS3 memory map. A 1:1 virtual map will give correct pointer values but also blows up the search space, and you'll hit the exact same problem that PR is working through. PR 515 shows using RC_MEMORY_TYPE_VIRTUAL_RAM in practice to keep searches manageable.

4. PS3 uses 64-bit pointers.
rcheevos does not actually support 64-bit reads, and RC_MEMSIZE_* stops at 32 bits. Obviously, the PS3 is a 64-bit system. For pointer chains, the workaround is reading the low 32 bits and translating to a physical address. This is the same approach we use for 64-bit data types elsewhere. This is our constraint, not yours, but it will influence the memory map's design.

5. Address stability needs to be verified.
The PS3 has a full operating system and MMU that runs in front of whatever game is being played. We'd like confirmation that addresses remain stable across sessions and firmware versions. Wii and DSi both have similar predicaments and have given us little to no issues, so we're not worried, but would like this confirmed.

6. Hashing also needs a reference implementation in rcheevos.
PSP is the right system to reference for the hashing implementation. It hashes both PSP_GAME/PARAM.SFO and PSP_GAME/SYSDIR/EBOOT.BIN (see rc_hash_psp in src/rhash/hash_disc.c). PS3 should do the same with PS3_GAME/PARAM.SFO.

Hashing EBOOT.BIN alone isn't enough. The SFO carries serial and version info, so including it resolves conflicts when an EBOOT.BIN is shared across multiple releases, or between different games built on the same engine.

This doesn't have to replace an internal hashing implementation in RPCS3. It's fine to keep yours and add a reference implementation in rcheevos alongside it. Accessing the files directly is probably simpler than wiring up the virtual file system callbacks. PCSX2 does exactly this, with an internal implementation, plus the reference implementation in rcheevos.

Lastly (unrelated to the code), as we all know, PS3 games come with official trophy sets, and RA's achievement sets need to be original work. This is already our standing policy. I think we're all on the same page here. We'll need to write a policy at some point in our docs about how close an RA set can come to an official trophy set. Interestingly, there are cases where trophy sets for retro re-releases have 1:1 copied the RA set verbatim. This will be our problem to sort out, but feels worth writing here for the sake of transparency.

For immediate next steps: open the console ID, hashing, and memory map work as separate PRs into rcheevos. Smaller PRs tend to move faster. We'll also keep an eye on this PR.

[Alasonga]

@wescopeland tested address stability across multiple sessions and games using Cheat Engine's Memory Regions view and a runtime log of vm::g_base_addr attached to the RPCS3 process. Each session was a fresh boot of RPCS3 with a new game, same character name and class. (where applicable)

Cheat Engine confirmed the PS3 RAM block (_block_xc0000000, 256MB) mapped at 0x4C000000 across 2 sessions each for Demon's Souls (BLUS30443), Dark Souls (BLUS30782), and NieR (BLUS30481). Runtime logging confirmed vm::g_base_addr, the pointer from which the emulator reads PS3 RAM to feed rcheevos, resolved to 0x0000000300000000 across 3 consecutive sessions.

In-game data structures in Demon's Souls are dynamically allocated. Full validation of pointer chain stability via RAIntegration will be possible once RC_CONSOLE_PLAYSTATION_3 lands in rcheevos.

Testing was limited to a single firmware version.

Before opening the rcheevos PR for the console ID: I mapped the full enum in rc_consoles.h, the sequence runs 0-81 with no gaps, and 71 is already taken by Arduboy. The next available ID would be 82. Does the RA backend already have a specific ID assigned for PS3?

[wescopeland]

Before opening the rcheevos PR for the console ID: I mapped the full enum in rc_consoles.h, the sequence runs 0-81 with no gaps, and 71 is already taken by Arduboy. The next available ID would be 82. Does the RA backend already have a specific ID assigned for PS3?

Not yet. We'd be happy to allocate 82 to PS3. cc @Jamiras for visibility.