reSOT Recompiles Prince of Persia: The Sands of Time Xbox Demo for Native Windows 10 and 11

For Windows enthusiasts and software preservationists, the project is especially notable given the broader context surrounding the franchise. As Yahoo Tech reported in January 2026, Ubisoft cancelled its long-delayed official remake of Prince of Persia: The Sands of Time during a wider corporate restructuring, while the existing 2003 PC release has historically relied on community patch compilations on ModDB and PCGamingWiki to address widescreen formatting, XInput gamepad problems, and EAX audio compatibility on modern systems. Rather than patching the legacy Windows port or running the Xbox disc inside a traditional virtual machine, reSOT translates the console executable itself into a native host program—though its official documentation makes clear that there is still a sharp divide between its playable E3 2003 demo target and its early-stage NTSC retail bring-up.

Under the Hood: How Xbox-to-PC Static Recompilation Works​

When a project claims to run a console game on a PC "without traditional emulation," it is reasonable for veteran IT pros and developers to ask what is actually executing on the host CPU. In conventional console emulation, an emulator dynamically interprets or just-in-time (JIT) translates guest instructions at runtime while emulating the entire hardware stack. Static recompilation moves that translation step ahead of time.

According to the FulGerNet/rePOP documentation on GitHub, reSOT takes an original Xbox executable (default.xbe), which already contains 32-bit x86 instructions, disassembles it, identifies its function boundaries, and lifts every routine into C source code using a patched, vendored copy of the xboxrecomp toolchain. The repository maintains separate vendored copies of this recompiler and runtime under port/third_party/xboxrecomp-demo and port/third_party/xboxrecomp-retail. Once lifted, the generated C code is compiled through CMake and MSVC into a native 64-bit Windows binary.

What runs natively, and what gets intercepted?

• Lifted Game and Engine Code: The game's core Jade engine, its BigFile asset loader, compiled AI routines, the Bink video decoder, and even the statically linked Xbox Direct3D library run directly as compiled C code on the host CPU.
• NV2A GPU Command Translation: Because the statically linked Xbox Direct3D library continues to emit low-level pushbuffer commands meant for the original Xbox's NVIDIA NV2A graphics processor, reSOT provides a runtime pushbuffer executor. This layer translates those NV2A operations—including register combiners converted into HLSL—into modern Direct3D 11 calls executed by the user's PC graphics card.
• Kernel and Subsystem Replacements: Console-specific operating system calls, file I/O, threading, timers, interrupts, PVIDEO overlays for Bink movies, and emulated OHCI USB/input hooks are handled by a custom Windows runtime utilizing XInput and XAudio2.

In short, the game logic is executing as a native Windows x64 process, while the console's hardware assumptions are satisfied by a purpose-built compatibility runtime. The long-term objective stated in the repository is not only to make both supported Xbox builds fully playable from a user's own discs, but also to keep the generated C readable enough that functions can eventually be replaced one by one with hand-written source code.

Demo Milestone vs. Retail Bring-Up: A Tale of Two Builds​

One of the most important takeaways from inspecting the primary repository—and a detail easily missed if you only watch a showcase clip or read a summary blurb—is the difference in maturity between the two supported Xbox targets. An older listing in the Recompendium (xrecomp) community catalog had stated that retail work had not yet begun and that demo gameplay had not been verified by a human player, and a Reddit thread on r/decomps flagged that the showcase had been shared with an "AI assistance" label. However, the authoritative October 15, 2026 documentation in the FulGerNet/rePOP GitHub repository provides a detailed, function-by-function accounting of both builds.

The repository authors are refreshingly candid about what their status markers mean: a green status in their validation table means a component was observed working in local test runs, not that it has been verified as cycle- or pixel-accurate against real Xbox hardware. In fact, neither the demo nor the retail build has been formally checked side by side against a physical console yet.

What Works and What Remains Unfinished​

In the E3 2003 Demo, the October 15 milestone polished several quality-of-life features for modern displays:

• 16:9 Hor+ Presentation: The viewport expands horizontally to fill a 16:9 monitor without stretching, frustum culling is widened so geometry does not vanish prematurely at the screen edges, the pause menu's Prince silhouette and backdrop span the full width, and double-compression artifacts on the upper-left health and sand crescents HUD have been removed. (One quirk of expanding a 2003 asset: the 3D menu garden was never modeled by the original developers past its 4:3 border.)
• Runtime Overlays and Shortcuts: Pressing F5 toggles a compact translucent performance and scene panel (which displayed scene 01_GP01_E3_Long during testing), while F6 opens an in-game configuration menu for graphics, VSync, frame rate caps, and input remapping. Alt+Enter or F11 toggles full-screen mode, Space or controller A skips Bink video sequences, and Alt+F4 cleanly exits the process.

Even in the demo, however, several rendering and audio subsystems remain partial. Character shadows are rendered as projected silhouettes, while stencil shadows and cube maps are not yet implemented. On the audio front, DirectSound runs through an emulated APU layer, but no DSP effects are present, and a per-voice resampling fix is currently being tested to resolve user reports of high-pitched sound.

For the NTSC Retail version, the developer solved an initial invalid-refresh timestep bug that had locked gameplay into extreme slow motion—bringing a measured slice of gameplay to 9.003 real seconds per 9.008 simulation seconds—and ported the demo's 16:9 projection and culling hooks to the retail executable's memory addresses. Still, retail remains the next active development target rather than a finished port, with user reports noting that the game still feels slower than normal despite reporting 60 FPS, and with only the opening in-engine scene validated so far.

How to Build and Run reSOT on Windows 10 and 11​

Because static recompilation projects rely on exact memory addresses mapped to specific binaries, reSOT strictly enforces SHA-256 verification on the input default.xbe file and refuses any other disc revision. Furthermore, to stay squarely on the right side of copyright law, the GitHub repository contains zero Ubisoft game assets, zero original binaries, and zero pre-generated C code. Everything lifted from your disc stays local on your machine.

If you own the matching Xbox demo or NTSC retail disc and want to test the toolchain on a 64-bit Windows 10 or Windows 11 system, the repository outlines a straightforward build workflow:

1. Prepare Your Development Environment: Ensure you have a 64-bit installation of Windows 10 or Windows 11 with Microsoft Visual C++ (MSVC), CMake, PowerShell, and Direct3D 11 / XInput / XAudio2 support.
2. Extract Your Disc Assets: Copy the files from your legally owned Xbox disc into the repository's ignored Assets/ directory:
   • For the demo, place default.xbe, prince.bf, video/, and sound/ inside Assets/xbox-demo/.
   • For retail, place default.xbe, prince.bf, shaders.bin, VIDEO/, SOUND/, MEDIA/, POP1/, and POP2/ inside Assets/xbox-retail/.
3. Verify the Executable Hash: Confirm that your default.xbe matches the exact SHA-256 checksum listed in the table above (79C1A4... for the E3 2003 demo or 753C58... for NTSC retail).
4. Run the Recompilation Script: Open PowerShell in the repository root and run:
   .\tools\recomp.ps1 -Target xbox-demo
   This script analyzes the Xbox executable, lifts its routines into C under source/<target>/gen, and compiles the native x64 Windows executable. (Note: default.xbe is used as a build input and embedded into the compiled executable, so it does not need to sit next to the final player binary, though the game data folders do.)
5. Launch the Game: Start the compiled build in full-screen mode by running:
   .\tools\run.ps1
   Alternatively, you can generate a desktop shortcut using .\tools\shortcut.ps1 or launch the resulting executable directly from its portable output folder.

Licensing and Preservation Outlook​

From an open-source governance standpoint, reSOT's original host code is released under the MIT License, while the vendored and patched xboxrecomp recompiler and runtime components incorporate LGPL-2.1-or-later code derived from the xemu Xbox emulator project. Neither license covers the original game's assets or the C code generated locally on a user's PC.

While PC players looking for a start-to-finish playthrough of The Sands of Time today will still rely on the classic 2003 Windows release paired with community fix packs, reSOT demonstrates just how rapidly static recompilation is maturing on the original Xbox architecture. By turning a 2003 console binary into a native x64 Direct3D 11 Windows application with 11,215 lifted functions in the demo and 14,418 in the retail build, the project establishes a clean, inspectable foundation—not just for The Sands of Time, but potentially for the rest of the Xbox Prince of Persia trilogy that the rePOP repository aims to tackle next.