The runtime — how the port plays the game
Prerequisite: Engine architecture.
The format docs answer one question: what is in the bytes on disk. This section answers the other one: what the engine does with them at runtime — the behaviour that DFET never needed, recovered from TI.EXE and from observing the real game.
The two are kept apart deliberately. A format page stays true as long as the 1996 files don't change; a runtime page describes living code that gets refactored. Runtime detail in a format doc ("how the UI band is drawn", "how a cricket pans") goes stale with every refactor, so the format pages stick to bytes and link here for behaviour.
The pages
Read in any order — each names its own prerequisites.
- Timing — the heartbeat, loops, crickets & walks — the two time bases,
makeloop's one-shot-that-re-arms model, positional ambient sound, actor walks, and the game clock behind the pocketwatch. - The sinking — how mission 4's clock runs — the one level played against a clock, and why that clock counts engine passes rather than seconds: the heartbeat, the conversations, the phase timetable's hold, and the movement bump that makes turning in place cost you the ship.
- Stage & UI — flats, overlays and the click order — the
StageController: how a stage opens, the overlay stack behind the inventory, and exactly who gets a click first. - Characters — actors & puppets at runtime — walking CST sprites in the world and PUP conversation close-ups: facing math, occlusion, speech pacing, subtitles and choice bevels.
- Audio at runtime — channels, banks & volumes — the three playback channels, how a name finds its bank, the two-slot
currentsoundmodel, and the volume controls (including one deliberate divergence). - Saving & loading at runtime — what a save snapshot contains, the script-free load that restores the engine from the file rather than re-running the room, and the in-browser saved-games UI with its IndexedDB "file system".
- The browser host — the part that is neither format knowledge nor recovered behaviour: the page and the cold boot it starts, the
SetViewernavigation state machine, the movie player, input wiring, and the developer toolbar. - The low-memory game — the smaller version of itself the game shipped with: what
BOOTFILE's ownlowmemory()switches off, why.11Kis not 11 kHz, and the one number the port moves to let a player hear it. - Languages & the chooser — one data tree per language, how a bare filename resolves through two selectors (disc and language), the code page a tree's text is in, and the language chooser: this port's own DreamFactory stage, scripts and all.
- Rooms in play — DreamFactory 5 — RedJack's rooms: the scripts that do the moving, the camera sprites are drawn through, how big a sprite is, pictures that stand in the room, and the two depth sources that hide a sprite, at a node and on film.
- TH mode — Titanic and Dust on a wide display: the room's view alone, with the menu band tucked away until it is wanted.
Where the code lives
Paths are relative to engine/src/ — runtime/ is the recovered engine, web/ is the browser layer around it, df/ is the format library (the architecture map has the full inventory). The Page + input row is a game's code rather than the engine's, and is named as such.
The interpreter itself — scopes, operators, the event chain — is a language topic and stays in the scripting doc; the full command list is in the builtin reference.
Start with the one everything else leans on: Timing.