ps3recomp turns PS3 titles into native C, one platform at a time

Ahead-of-time translation instead of a runtime emulator

ps3recomp is a C and Python toolkit for turning PlayStation 3 binaries into native PC executables. The approach is the opposite of emulation: nothing interprets PowerPC or SPU instructions while the game runs, because a lifter translates the original code ahead of time into C and C++ that any modern compiler can build. That makes it a preservation and modding tool rather than a game player, and the README frames the goal as giving the Cell Broadband Engine a second life. The audience is people who want a PS3 title running on a desktop as ordinary software: a native binary a debugger can step through, a patch can change, and that keeps working after the last emulator release stops. The README cites a catalogue of more than 3,000 titles and notes that RPCS3 has made roughly 70 percent of the library playable, so ps3recomp is not chasing what emulators already do well. It is chasing the cases emulation leaves open.

The Python pipeline that turns PPU and SPU code into C

The analysis half of the project lives in Python scripts under tools/, and the naming tells you the whole flow. elf_parser.py parses PS3 ELF, SELF and PRX binaries. ppu_disasm.py disassembles PowerPC including the console's custom instruction extensions, and ppu_lifter.py turns PPU assembly into C. spu_disasm.py and spu_lifter.py do the same job for the SPU instruction set. extract_spu_images.py pulls embedded SPU images out of PRX and ELF containers, find_spu_functions.py and find_functions.py detect function boundaries, and wrap_spu_elf.py turns a raw SPU blob into a loadable ELF. prx_analyzer.py inspects PRX imports, exports and NIDs, nid_database.py resolves those Function Name IDs, and generate_stubs.py produces high level emulation stub skeletons from a NID list. All of it is offline work on binaries you already hold, which is why the toolkit feels closer to a compiler toolchain than to a game engine.

Why the PPU boot scaffold still holds macOS and Linux back

Runtime support is uneven, and the platform table in the README is blunt about it. The runtime library builds on Windows with clang-cl, on macOS arm64, and on Linux with GCC and Clang, and the lifter test suites plus the C unit tests pass in all three. Running an actual recompiled title in this tree is a Windows-only yes. The blocker is named directly: the PPU boot scaffold. ppu_loader.cpp, boot_main.cpp and the high level emulation dispatch are compiled per game rather than shipped inside the library, and those per-game files compile on POSIX with zero errors, but no title has yet been booted to gameplay from this tree on either macOS or Linux. The frame clock does run there, so the gap sits in the game-specific boot path rather than in timing. Community work has gone further: Twisted Metal menus running on Linux and Vulkan, inFamous on macOS, Killzone 3 under Proton. Those ports carry patches that are still on their way upstream, which is why the table still says no.

The render backends run further ahead than the game boot path

Graphics sit in a different place from game boot. ps3recomp_host drives cellGcm through RSX to a backend with no game attached, and the README states that every scene in that host passes on both Metal and Vulkan, including render to texture, multiple render targets, depth textures, cube maps and stencil. With guest programs enabled, both backends run the title's own shaders on a shared register file draw engine. On Linux the default stays the headless null backend, a CPU triangle filler that continuous integration draws with. The practical read for a new contributor is that the render path has a wider test surface than the loader, so it is the easier place to land a first change. The catch is that renderer work does not move the boot table, and a working host scene is not evidence that a title runs.

Installing the analysis tools and their Python dependencies

Here the documentation runs out. The README does not give a single install command for the native runtime, and there is no package manager entry in the project. What it does ship is the Python dependency file, and the install line for it is stated plainly. A first real use starts there.

# Install with: pip install -r requirements.txt

Run that from the repository root and the tool scripts become importable. The dependency list covers ELF and SELF decryption, PowerPC disassembly, structured binary parsing, pretty command line output, TOML config parsing for Python versions before 3.11, and progress bars for the long lifting passes. After that you point the scripts at a binary you own and read the generated C. The repository root carries a CMakeLists.txt and a cmake/ directory, so the runtime itself is a CMake project, but no build command is printed for you to copy, and the exact flags are not stated.

The runtime tree covers registers, memory and the LV2 kernel

The runtime directory holds the parts that survive the translation step. Under runtime/ppu, ppu_context.h defines the register file, condition register, link and count registers and the floating point status and control register, ppu_memory.h provides load and store macros with byte swapping, and ppu_ops.h holds instruction operation macros. The SPU side mirrors it: a 128 by 128 bit register file, a 256KB local store and an image id in spu_context.h, channel operations with per-image function table dispatch in spu_channels.c, intrinsics in spu_helpers.h, and a DMA transfer engine in spu_dma.h. Below that, runtime/memory/vm.h implements a virtual memory manager over a 256MB address space, and runtime/syscalls carries the LV2 kernel work: thread creation, mutex and condition variables, memory allocation and mapping, filesystem operations, and a full syscall dispatch table. The high level libraries under libs cover audio and video, with cellAudio, cellAdec, libmixer, libsnd3, libsynth2, cellGcmSys and cellRes listed.

What static recompilation costs against an emulator

RPCS3 is the honest alternative, and the README concedes that the emulator handles the library well. The difference is architectural. RPCS3 interprets and dynamically recompiles instructions, keeps the guest binary in its original form, and emulates the whole machine in software. ps3recomp translates ahead of time, so what you get is source code you can compile, read and patch, running at native speed with no translation layer in the way. The bill arrives up front instead. A recompiled title needs working lifter output for every PPU function, correct SPU handling, a usable system call surface and a per-game boot scaffold, and each gap in those pieces shows up as a startup crash rather than a dropped frame. The same trade is visible in the sibling projects the README lists, from N64Recomp and UnleashedRecomp through PS2Recomp and AnyPS5, each of which re-targets a different console the same way.

Recent tags, MIT terms and the real cost of a port

The repository is not archived and the last push was on 2026-10-19. Three tagged versions landed in the week around it: v0.16.0, code named Forty-Four, on 2026-10-19, v0.15.0, Seventy-Six, on 2026-10-16, and v0.14.0, Outside In, on 2026-10-13. The project is licensed under MIT, so the runtime, the lifter scripts and the high level stubs can be reused inside a port of your own, subject to the usual obligation of keeping the notice. What adoption actually costs is engineering time rather than licence money, because each title needs its own boot scaffold, its own stub coverage and its own debugging sessions. Two things to check first in a fresh tree: whether a game-specific loader is already present for your title, and whether the renderer your title depends on has a non-headless backend on your platform.

Editorial conclusion

ps3recomp fits engineers who want to read, patch and preserve PS3 code as native C/C++, and it does not fit people who expect a plug and play player. Before starting a port, check whether the per-game boot scaffold and the high level stub coverage you need already exist in the tree, because the platform table shows title boot working on Windows only, and track the tags closely, since the last push was on 2026-10-19 and versions were landing several days apart.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sp00nznet/ps3recomp on GitHub