RYU6Recomp

Rehosting a console binary as a native Windows application

Apr – Jul 2026

shadPS4 emulation — The before/after: the same cutscene under emulation (hair blocked, no alpha) and through the native rehost with the alpha-to-coverage fix.

Native PC — The before/after: the same cutscene under emulation (hair blocked, no alpha) and through the native rehost with the alpha-to-coverage fix.

Mesh region — The hair mesh (event 3013): its region in magenta, and its draw within the lit frame.

Drawn in-frame — The hair mesh (event 3013): its region in magenta, and its draw within the lit frame.

Mayu regions — The mayu meshes — dedicated eyebrow, sideburn and goatee detail geometry (event 3022) — and hair plus mayu drawn together.

The hair fix up close — hair, mayu and eyelashes all alpha-tested. RenderDoc backbuffer, frame 1377

RenderDoc: event browser, vertex buffers, mesh viewer

Lua test stage loading c_am_dummy — a real model from the game

Native PC in an early bring-up state — frames from my own renderer

Rendered natively through my Vulkan renderer

The problem

A console binary assumes its home platform: a fixed GPU command format, a shader bytecode no desktop driver understands, and a display pipeline whose timing guarantees the OS makes implicitly. Running one on PC means rebuilding each of those assumptions explicitly, without access to any original source.

Approach

Static analysis of the shipped executable in Ghidra to recover structure and entry points.
Translation of the console GPU's shader bytecode into SPIR-V so desktop drivers can consume it.
A Vulkan renderer for the frame replay and present path, debugged against the Khronos validation layers rather than against visible symptoms.

Outcome

Produced a write-up of a write-after-read hazard on the swapchain that was invisible on my development GPU and only surfaced under synchronization validation — including the fix and, honestly, the separate bug it did not fix.

Built with

C++
Vulkan
SPIR-V
Ghidra
RenderDoc

Read the writeup