Skip to content

Architecture

Jump to bottom
Sinan Karakaya edited this page Sep 24, 2026 · 2 revisions

Architecture

DQ8Recomp translates Dragon Quest VIII's PlayStation 2 Emotion Engine (EE) code to C++ ahead of time, then compiles and links it with a host runtime. The repository contains the tooling, runtime integration and configuration. Users supply the original game data; generated game code and extracted assets are local build inputs.

The active gameplay target is the NTSC-U release, SLUS_212.07. PAL configuration and format research also exist, but do not establish equivalent gameplay support. See Project Status and Building.

Execution path

User-supplied executable and overlays
    → PS2Recomp translation
    → generated C++
    → host compiler and linker
    → native game functions + runtime services

Guest DMA/VIF commands
    → VU execution
    → GIF packets and GS state
    → software or SDL GPU rendering
    → host presentation

Static recompilation applies to the game's EE code. Runtime handling of console devices is still necessary. VU microprograms use a mixture of ahead-of-time compiled specializations and an interpreter fallback; this is described in Vector Units. Optimized device execution must preserve guest-visible behavior and timing.

Source map

Location Responsibility
thirdparty/PS2Recomp/ Recompiler and shared PS2 runtime: guest memory, scheduling, kernel/services, VIF, DMA, VU and GS frontend
src/runtime/ DQ8 entry point, host integration, game-specific hooks and overlay dispatch
src/gfx/gs/ Shared GS memory, transfer and state support
src/gfx/backends/sdlgpu/ SDL3 GPU renderer, targets, textures, input and presentation
src/gfx/gsdump/ Graphics capture readers and replay support
config/<version>/ Revision-specific recompiler inputs and address maps
tools/ Asset-format tools, analysis, graphics tests and runtime replay tools

PS2-generic fixes belong in the PS2Recomp submodule. DQ8-specific behavior and Level-5/Metrowerks formats belong in the parent project. Keep the submodule revision and its integration changes together when reviewing a change.

Overlays and services

DQ8 loads several code overlays into a shared guest address range. Each overlay is translated into its own namespace. The overlay manager selects the resident overlay's dispatch table when guest execution enters that range. The same guest address can therefore identify different functions at different times. Use the selected version's configuration rather than copying addresses between releases.

The runtime implements guest memory and console services, including scheduling, interrupts and selected SDK/RPC interfaces. These interfaces are incomplete in places. Native EE execution does not imply that every service the game calls is implemented.

Sound is the exception to reimplementing services. The game's own IOP sound modules (LIBSD, SDRDRV, the Standard Kit modules and PCMPLAY) run unmodified on a small emulated IOP with an R3000A interpreter, a high-level kernel and both SPU2 cores. The game reaches them over SIF RPC and DMA as on a console, and IOP time advances with the samples the host audio device takes. The PS2Recomp ps2xIOP readme describes it in detail.

Graphics concurrency

The GS frontend preserves command order and sends backend operations through an ordered worker in normal SDL GPU gameplay. CPU-visible reads, reset and other observations require the corresponding synchronization. The renderer tracks whether GPU textures or GS local memory own the newest data.

Presentation tickets hold immutable snapshots with explicit GPU lifetimes. Preparing a snapshot and displaying it are separate operations, so a window wait need not hold the producer's submission lock. This separation does not itself unlock higher frame rates. See Graphics.

Timing and future extensions

Guest EE cycles, VU cycles, VBlank events, completed game renders and host presentations are distinct quantities. An optimization must preserve guest-visible timing, interrupts and I/O ordering. Raising guest clock charges or issuing extra VBlanks is not a display-frame-rate option.

Future configurable presentation rates can build on stable snapshots. Additional distinct animation frames would require separately validated rendering or interpolation work. Custom FPS options, a public mod API, language switching and 3DS content integration are future work, not current capabilities.

When contributing, preserve these boundaries and validate changes at the layer they affect. Testing describes the correctness and performance checks.

Users

Developers

Clone this wiki locally