4be90c2805
Last iteration left "is 9.7 fps llvmpipe or something in our draw path" open after publishing a candidate cause off it. That is not a question to leave open, so this iteration is the control. Pre-registered: if the rasteriser is the limit, a near-empty scene in the same container also runs at 10-25 fps; if our draw path is, it runs far faster, take >100 fps as the discriminator. empty 161.6 fps The engine loop, viewport and present path are not the limit, by 16x over the menu. 🔴 AND MY FIRST CONTROL WAS NOT A CONTROL. Its fill modes drew UNTEXTURED rects while every element the port draws is a texture, so it bounded nothing -- and it showed: the splashes were achieving ~21 Mpx/s against that control's ~50, which read as the port being mysteriously slow and was the control being mysteriously fast. With a matched textured mode: empty 161.6 | fill3 31.5 | tex3 23.9 | fill7 12.7 | tex7 11.2 and every port screen lands inside the bracket, ordered by large-quad count: publisher (1 quad) 17.3-25.0 ~ tex3; developer (1) 16.7-22.8 ~ tex3; title (6) 12.7-17.2 between; main_menu (5) 9.7 ~ tex7's 11.2. The port draws large textured alpha quads on a software rasteriser at exactly the rate a software rasteriser draws them. ⚠️ The control's own spread is 1.75x between runs (fill3 measured 18.0 once and 31.5 once), so the absolute figures are noise-dominated and only the ORDERING and the BRACKET are load-invariant. That is what the conclusion rests on -- TEMPORAL-VERIFICATION §3, prefer the quantities with no phase. 🔴 SO MY OWN CANDIDATE FOR FINDING 4 IS DOWNGRADED, AND THIS SAYS SO PLAINLY. Last iteration called the frame rate "the first candidate for finding 4 that is not already dead". The quantisation argument still holds -- a fade drawn in four steps is not a fade drawn in fifteen -- but it only bites at these rates, and these rates are a property of software rasterisation in this container. Five to seven full-screen quads at 720p is nothing to a GPU. Unless the human ran the port software-rendered, this is not what they saw, and EVERY candidate for finding 4 is now dead or near-dead. Written as a dead end rather than left standing as a lead. Leaving a plausible-sounding cause up after its own control has undercut it is exactly how "close but not right" got explained four different wrong ways. The one thing that would revive it costs the human nothing: the rate line prints on every boot now, so their next run answers it. What the port does NOT need, established rather than assumed: no draw-path optimisation (161.6 fps empty, screens on the fill curve where their quad counts put them), no texture caching (already at load_screen), no max_fps or vsync change (would not raise the rate here, and is a presentation decision not a defect). Not settled: what rate the human's machine manages -- now the only open half of a candidate I have otherwise talked myself out of; H6's +0x04 exposure; H1 (with the Decoder); the four red verify-screen rows. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
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-cliand 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
-- and RUNNING.md, which is how you actually start it
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
docs/re/INDEX.md— what is decodeddocs/re/REFUTED.md— what has been tested and dieddocs/re/METHOD.md— traps this project has already paid fordocs/game/navigation.md— how the game is navigateddocs/port/MODDING.md— why the asset tree looks the way it does
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.