sylph-decoder e07c1de1b5 re: I cannot measure this emulator's clock -- and that answers the port's 2%
The port put two of my pages against each other: settle->plate 2.135 s and one
focus-ring revolution 2.177 s, both a declared 120 units during a static hold,
2% apart against a 6 ms run-to-run agreement. Fair challenge.

The resolution is that the question assumes a stable wall clock. Same interval,
same container, same day: 2.138, 2.132, and 2.549 s -- a 19% swing, caused by
adding --log_ui_draws=true. The 2% is a fifth of that. The two pages were never
in conflict about the game; they are three readings of one declared quantity
through a clock that moves. What settles the quantity is the disc.

Wall clock cannot separate the hypotheses, so I tried to measure frames instead.
Both instruments are recorded as failures rather than published as numbers:

  * Canary's own [UI-CAP] counter -- the one that produced the corpus's 28.5 fps
    -- costs a third of the frame rate. 300 frames in 16.567 s = 18.11 fps on a
    screen that gives ~28 without it. That reclassifies 28.5 as a load-dependent
    lower bound; it does not overturn it.
  * A distinct-frame counter over the spinning ring FAILED its decisive control:
    15.88 fps against the game's own 17.59 in the same window, 10% low, so the
    ring does not change on every presented frame. Its static control also read
    2.63 instead of ~0. Dead, not tuneable, per METHOD.md.

The rule that follows, and it applies to everything I hand the port: a measured
interval landing near a round number of declared units almost certainly IS that
number of units. Ship the units.

Also recovered here, because the same question needed it: the static PPC route.
Four tools open /work/xenia-rs/sylpheed.db and nothing in this repository builds
it -- no disassembler, no PPC decoder, and default.xex is encrypted (zero
plaintext "GamePart"). Xenia decompresses the image at load, so dump_image.py
reads it out of guest memory and validates it against the corpus's own landmarks:
the 29-entry GamePart id table at 0x820A1630 and the Xbox 360 D3D runtime
strings. String search and table dumps work again; instruction-level work does
not, and the present interval I wanted is an immediate, not a string.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLw
2026-08-29 13:16:02 +00:00

Sylpheed

A clean-room reverse engineering and port project for Project Sylpheed: Arc of Deception (Xbox 360, 2007).

Three things live here, in one repository so that a change spanning them lands as one commit:

The decoders crates/sylpheed-formats — the disc's formats, read and verified disc-wide
The port port/ — a Godot 4 project, plus crates/sylpheed-export which converts a disc into the open asset tree it reads
The corpus docs/re/ — what has been reverse engineered, with its evidence, its retractions and its dead ends

You need your own copy of the game. No game content is in this repository and none ever will be. The exporter reads the disc you supply.

The oracle is the real game

sylpheed-cli and the Explorer are tools for verifying our decoding. They are hypotheses under test and they have been wrong. When something must be checked against the truth, the truth is the game running in Xenia Canary, captured — not any renderer of ours.

This is stated first because getting it backwards is the most expensive mistake this project has made.

Layout

crates/
  sylpheed-formats/   the decoders. Disc-wide verified; the corpus is its spec
  sylpheed-cli/       headless tools -- render a screen, dump a table, probe audio
  sylpheed-viewer/    the Explorer: a human's window onto the disc. STATIC data only
  sylpheed-export/    disc -> the open, moddable asset tree
port/                 the Godot 4 project. Reads open formats ONLY
authored/             decisions that are NOT on the disc, each with its reason
data/
  base/               generated by the exporter. Gitignored, never hand-edited
  mods/               drop-in overrides. Yours
docs/
  re/                 the corpus: findings, refutations, method traps
  game/               how the game is navigated -- menus, modals, flight
  port/               the port's mission, its handoff contract, modding rules
  agents/             how the agent team works together
tools/                capture harnesses, probes, the share tool
exchange/             transient inter-agent files. NOT in git
docker/               the agent containers

Where to start

Xenia Canary is a separate repository: it is a fork tracking upstream, and it carries our instrumentation.

Conventions

Confidence is per claim, never per document: CONFIRMED · 🟡 PROBABLE · HYPOTHESIS · REFUTED. A withdrawn result is kept with its reasoning rather than deleted — that is why the numbers here can be trusted.

Description
No description provided
Readme MIT 820 MiB
Languages
Rust 57.6%
Python 27.7%
Shell 10.6%
GDScript 3.5%
Dockerfile 0.4%
Other 0.1%