Project Status

Project Status

DQ8Recomp is an experimental static recompilation of the PlayStation 2 version of Dragon Quest VIII. It is not yet a finished, consistently playable port.

Current support — October 2026

The active target is NTSC-U SLUS_212.07. The game reaches the title screen, loads into the opening sequence and field, and supports field movement and menu interaction with the SDL GPU renderer. Music, sound effects, speech and movie audio play through the game's own IOP sound drivers. These checks do not constitute a full playthrough or broad compatibility certification.

On an Apple M1 Pro, with VU1 programs compiled ahead of time, the opening field holds the game's own cap of 30 completed renders/s: 29.97 on average over a minute of walking, with the slowest two-second window at 29.4. Menus run at 60. Walking around Farebury's church also holds 30 once the area has loaded, with the slowest window at 27.3. Before the whole-program VU compiler and the renderer changes that came with it, the opening field ran at about 15.

setup.py recompile rebuilds those VU1 programs from the player's own ELF. A clean build therefore runs these routes at full speed with no recording session; the church figure above comes from such a build. Microcode outside the list falls back to the interpreter; see Vector Units. Other hardware and later parts of the game have not been measured.

A local optimization passing isolated tests does not become an accepted feature until its real replay and gameplay checks are complete.

Working foundations

• Native compiled EE game code and revision-specific overlay dispatch.
• SDL3 GPU rendering with resolution scaling, an ordered GS worker and immutable presentation snapshots.
• Ahead-of-time VU regions and selected retained loops, and whole VU1 programs compiled from the player's ELF or from local recordings, all with interpreter fallback and differential replay verification.
• The game's own IOP sound modules running on an emulated IOP and SPU2, in step with the host audio device.
• Guest scheduling and presentation boundaries kept separate so performance work does not accelerate game logic.
• An in-game menu (F1, or Guide on a controller): display and internal resolution, sound, controller and keyboard remapping, which controller plays, pause and fast-forward, screenshots and a frame-rate counter. See Running.

The last checked route showed no visible glitches, but known renderer limitations remain and wider game coverage is unfinished. See Graphics and Testing.

Priorities and unfinished work

1. Keep 30 FPS beyond the opening route and on hardware other than Apple Silicon, while preserving graphics and guest timing.
2. Listen more widely: sound has been checked through the opening, its movies, the field and the menus, not through battles, towns or later movies.
3. Broaden gameplay, rendering, save and platform coverage beyond the current test routes.
4. Develop stable extension interfaces and presentation options after the underlying execution is dependable.

Custom FPS or selectable 30/50/60/90/120/240 Hz presentation, interpolation, a public mod SDK, language switching, save states and 3DS content additions are future work. They are not supported features today. Higher display cadence must preserve guest logic and audio timing; repeating a completed frame is distinct from producing new animation frames.

Contributions are most useful when they include a focused reproduction, an authored regression where possible, and measurements at the affected layer. See CONTRIBUTE.md, Architecture and Testing.