OpenPeteDownloadA native PC port of Spyro the Dragon. Named after Spyro's name during original development. A statically recompiled and progressively replaced by a byte-matching decompilation, on a custom Vulkan renderer that draws directly from game state.
OpenPete needs your own copy of the original NTSC-U disc (SCUS-94228). No game data is distributed. The build is unsigned, so Windows will warn the first time you run it—see known issues, and the FAQ for the checksum to verify the download against.
The retail executable is statically recompiled into C. Its PSX library calls are serviced by a host runtime, and function by function that recompiled code is replaced with hand-decompiled C that assembles back to the same machine code the original shipped.
The renderer works directly from game state rather than from a stream of PSX GPU commands, so it knows what a polygon is and not just where it landed, allowing full control over presentation. This allows rendering with true depth, high frame rate, arbitrary aspect ratio, no PSX wobble and correct texture perspective with high resolution.
Gameplay is untouched. With the exception of mods, enhancements are presentation-only by construction, with the game simulation compared against emulator memory traces.
Drag the divider to wipe between the original PlayStation output and OpenPete. Pick a frame rate and aspect ratio, and toggle enhancements, to change what the right-hand side is running.
Rendering is decoupled from simulation. The game still ticks at 29.913 Hz exactly as it did on hardware; presentation runs at any framerate your PC can support with transforms, animation and scrolling textures interpolated sub-tick.
Hor+ widescreen (16:9, 21:9, 32:9, etc. or follow-the-window). Extending the aspect ratio does not affect gameplay such as enemy behavior.
Drop replacement PNGs of any resolution into a folder and they display in place of the originals: world, mobys, HUD and the title logo alike.
The low-poly and low-resolution LOD tiers can be pushed far back or switched off entirely, with fog scaled to match, so distant terrain keeps its detail instead of snapping in.
By default, vertices keep their full precision, textures are sampled with true perspective correction and colour is full 24-bit. Toggles recreate the console's vertex snapping, affine texture mapping and 15-bit dithered colour, for when you want the hardware's exact look.
Geometry is depth-tested rather than sorted through the PlayStation's ordering table, so the sorting artifacts inherent to a painter's algorithm don't occur.
Snapshot and restore anywhere, step frame by frame, rewind, or run ahead of the simulation to cancel out input latency.
Source-first mods, C and shaders both, compiled when the game starts, with no toolchain to install. They can override game functions, add post-processing chains and select materials.
Any of the 48 music tracks can be replaced with a WAV file. The game still drives looping and the long-idle track rotation, so overrides behave like the originals.
A pause-menu-styled overlay, drawn with the game's own gold glyph text, changes aspect, frame rate, supersampling, LOD, textures and wobble live.
Windows 10/11 (64-bit)
Nothing in the build demands a particular Windows version; the limiting factor is Vulkan 1.2 driver support.
Any x86-64 CPU
Any 64-bit Intel or AMD chip. Roughly anything from the last 15 years should be fine.
A GPU with Vulkan 1.2 support
Roughly a GeForce GTX 600, Radeon HD 7000 or Intel HD 500-series and newer, on a current driver. There is no Direct3D or OpenGL fallback. Around 2 GB of VRAM at 1080p with SSAA ×4.
8 GB recommended, 4 GB workable
Playing takes about 300 MB.
~1.2 GB once first run finishes
The download unpacks to ~450 MB, most of it the bundled compiler. First run then copies your disc image into library/ (~640 MB) and writes the code it compiles from it alongside (~90 MB).
Open
The PSX OT rendering covers up issues in the original game's geometry that are exposed by rendering with a true depth buffer.
Open
Rendering cutscenes at widescreen aspect ratios reveal missing geometry or mispositioned mobys.
Platform
Until code signing is in place, SmartScreen will warn on first run or antivirus may report false positives. The build is safe, but you may need to override any warnings.
FAQ
Yes. OpenPete ships no game data at all: no levels, textures, audio or code from the disc. You supply an original NTSC-U Spyro the Dragon disc image (SCUS-94228), which is verified by checksum before anything runs. Only a .bin/.cue disc image with the sha1 hash 1e08ae8df01acf7ee5d9cb6931b5f8c1bc905fcb or sha256 hash 95f03abf97c9ff0b2a64888ed7dbbb4b59a7b4363cf188cd0a562b95cfd4809f is supported right now.
No. The game's machine code is translated to C ahead of time and compiled for your CPU, and a host runtime provides the console's system calls. No hardware is simulated and no BIOS is involved.
NTSC-U SCUS-94228 only. Other regions and revisions have different code layouts, and the port's function addresses and overlay maps are specific to this one. Support for other releases is possible but not planned.
No. Widescreen, frame rate, draw distance and texture replacement are all presentation-only by construction. They never write to the game's memory or to anything the game can read back. Regression tests compares simulation output against emulation traces to catch any leak.
Yes. Saves are written to an ordinary .mcr memory card image on your disk, the same format emulators use, so you can bring a card across in either direction.
Game:
OpenPete:
No plans yet. The runtime is deliberately game-agnostic: it holds no Spyro-specific addresses, and per-game details sit behind a narrow interface.
Soon™. Mods are written as C source and shaders, compiled when the game boots, with no development toolchain to install. They can override game functions, add post-processing, select materials, replace textures and swap music.
The modding SDK does not ship with this release: the API is still in heavy flux and is being stabilized. It should follow shortly after.
The simulation is pinned to the console's 29.913 Hz tick and never runs faster. Extra frames are generated by interpolating transforms, animation, camera and texture scroll between two simulated ticks, so motion is smooth while physics, timing and behavior stay exactly as authored.
Not recommended yet. Times from OpenPete are not comparable to console or emulator runs, and no leaderboard recognizes it as a platform.
The two gaps that matter most are tick pacing and input timing. The simulation is meant to advance at a fixed 29.913 Hz, but host-side work can still stall a tick: a slow present blocks the simulation thread, so how the game behaves under load depends on your machine rather than on the game. Input has the same shape of problem, because the compatibility layer's event loop decides when a press is sampled and therefore which tick it lands on.
Both fixes are structural and both are on the roadmap. Moving GPU waits off the simulation thread stops a slow present from stalling a tick, and taking direct ownership of the window, event loop and input fixes where in the tick a press is read. Behind those sit load timing, which currently completes as fast as your disk allows rather than at drive pace, and determinism enforcement. Save states, rewind, runahead, and non-whitelisted mods (e.g. simple skins) would need locking out.
Windows on x86-64 is what is published today. Linux builds and runs from source already and a packaged download follows shortly; macOS on Apple silicon is planned but has no build yet.
The Windows zip for v0.1.4 has the SHA-256 hash 7ba215834c6a1e23d0642b6c749c6335853a18cc566805c0a39bcf2cd5ab1359. In PowerShell, Get-FileHash openpete-v0.1.4.zip prints the same value if the file arrived intact.
Checking it matters more than usual here, because the build carries no code signature to vouch for it.
OpenPete is based on a matching decompilation of Spyro the Dragon: an effort to rewrite the game in C such that the same compiler reproduces the retail executable byte for byte. If the bytes match, the C is what the game does.
Matching every function takes years, so the port doesn't wait on it. Static recompilation covers whatever hasn't been decompiled yet, and matched functions replace it as they land.
Special thanks to altro50, for his continued work on reverse engineering and decompilation of Spyro 1.