What Legend of Legaia is doing under the hood: what loads when you walk through a door, how a battle turn resolves, why the world-map ocean shimmers, how a cutscene plays. Each page here covers one piece of the engine - what it does in the game, where its code lives, and how it hands off to the next piece. The map below shows how the pieces connect; click any box to open its page. Start with Boot path if you're new, or Engine reimplementation if you're here for the Rust port.
The map
Almost all of the game happens in the field - walking a town, talking to people, opening doors. Everything else is a place the field hands you off to and gets you back from: a battle, the world map, a movie, a minigame, a menu. Under all of it sit three services that every mode uses: the asset loader, the renderer and the sound stack.
The field is the hub. Every arrow out of it is a hand-off the scene's own script or the pad makes, and each round trip ends with the field scene reloaded or resumed. The world map can start battles too (its regions roll encounters the same way a town floor does). Shops and the save screen are drawn by the menu overlay; an inn is not - it is an ordinary conversation in the town's script.
Where the code lives
The game shipped without symbols, so a routine's RAM address is its name: FUN_8002735C is one specific traced function in the project's dumps. Half the runtime lives in the main executable SCUS_942.54 and is always in memory: boot, disc reads, the asset router, two of the bytecode VMs, the audio and rendering libraries. The other half is overlays - chunks of code streamed off the disc into one shared RAM window when a mode starts. Only one of them is resident at a time, which is why the world map, save, shop and level-up screens are parts of the field, menu and battle overlays rather than overlays of their own.
Battle loads over the field overlay and the menu over either, so the game never holds two of them at once. The title screen is the tail of PROT entry 0899 (boot); the world map keeps 0897 and swaps only its first 0x4000 bytes for 0981. "Zero callers in the executable" therefore never means dead code - the caller is usually in an overlay.
How this section is organised
The pages follow a player's path through the game: power on, walk a town, the interpreters that script it, a fight, the overworld, the menus and the side games, then the picture and sound under all of it. Pages about the Rust port and the site's own viewers sit apart in the last group, so every group before it describes only the shipped game. The sidebar uses the same groups in the same order.
A large subsystem has a readable tour page plus companion pages: internals for the reference tables a tour leaves out, and capture notes for the measurements behind its claims. Companions are indented under their tour in the sidebar and marked below; read the tour first.
Startup and loading
From the disc spinning up to the title screen, and what every later mode leans on to get its assets into memory.
Most in-game behaviour is authored as data - scripts the designers could change without recompiling - and run by a handful of small interpreters. Four are clean opcode dispatchers; the effect VM is a per-slot state machine with the same role. The VM inventory lists every interpreter-shaped subsystem, including the ones too small for a page of their own.
From the encounter flash to the level-up window, in the order a fight runs: the overview, one round end to end, the command menu, the action machine and its byte queue, the summon modules, the arithmetic, and the spoils.
The from-scratch Rust engine and the site's own viewers. These pages describe this project's code, not the retail game; each links back to the retail page it reimplements.