Sylpheed port agent 7c8e4a863a port: adopt the game's 61% stick threshold, and find my verify-screen numbers were llvmpipe-specific
Two things, and both are about a hidden parameter nobody was recording.

1. THE STICK THRESHOLD IS DECODED NOW, and it replaces an authored value.

The Decoder measured that the game digitises the left stick to four direction
bits at 61 % deflection, so it never sees a velocity. Gamepad.ENTER moves
0.5 -> 0.61. The 0.5 was never a chosen value: it was a FLOOR, because Godot's
`ui_*` action deadzone is 0.50 and the latch must not arm below it. Between 0.50
and 0.61 Godot reports a direction the real game does not, and at 0.5 this port
stepped there.

The mechanism also corroborates the human's latch fix rather than merely
agreeing with it: a control that digitises to bits cannot express a rate, so
"one step per deflection" is what the hardware layer CAN produce.

⚠️ The 0.11 hysteresis gap stays AUTHORED -- nothing says the game has
hysteresis at all. And a human chose 0.5, so this changes feel: revert the one
constant if 0.61 reads as needing too much push.

🔴 AND THE CONTROL CAUGHT MY FIRST ATTEMPT AT ASSERTING IT. I added the new
device-level row as subject "latch", and `verify-input --control` failed
immediately with "a check did not invert -- it is not testing what it claims to
test". It was right: removing the latch does not remove the THRESHOLD, the
unlatched path tests `>= Gamepad.ENTER` too, so 0.55 counts 0 either way and the
row could never invert. It is a NEGATIVE, and its positive control is the 0.70
row on the same shape. Reclassified.

That also exposed a smaller thing: ok()'s negative branch HARDCODED "positive
control is the stick row", so a second negative would have borrowed someone
else's green line. It now takes the control's name, defaulting to the original
text so the d-pad row is unchanged.

 I never consumed the pad bit table they have just corrected -- checked by grep
over port/, authored/ and tools/port/, not remembered.

2. MY verify-screen NUMBERS WERE llvmpipe-SPECIFIC, and the prediction failed.

Pre-registered: both renderers blend in encoded 8-bit space, so the diffs should
be identical or within 1 level on the GPU. They are not -- every mean rose 3-35 %:
title 0.4431 -> 0.5936, main_menu 3.9363 -> 4.1449, extras 6.7422 -> 6.9757,
title_jp 2.7715 -> 2.9448, main_menu_jp 0.7885 -> 1.0157, extras_jp 0.6592 ->
0.8906, build_12/15 0.0368 -> 0.0454.

But the MAXIMA are unchanged -- 41, 97, 113, 233, 17 identical, 26 -> 27 on one
row. That is a rounding population growing, not content moving: two rasterisers
round the last bit of a blend differently while the elements that genuinely
differ do not move.

Survives: the additive diagnosis, because it rests on an ORDERING and the
ordering holds (9 elements > 5 > 0); the pgloading_loop5 localisation; the
build_00/01 agreement; the derived allowance, same four failing rows.

Does not, and is now labelled: the histogram (53 % within 1 level, 16 844 over
40); every absolute mean; and the RMSE-vs-capture pair 3151.96 / 3769.61 -- that
ORDERING claim is not re-derived on the GPU and is not claimed until it is.

The rule this earns: a renderer comparison carries its RASTERISER as a hidden
parameter. Nothing here recorded which one produced a diff, and for months there
was only one so it never mattered. Same discipline TEMPORAL-VERIFICATION already
demands for capture rate, applied to what rasterises rather than what clocks.

Not settled: H1's repeat half; H6's +0x04 exposure; the four red verify-screen
rows; whether the port is still nearer the capture than the reference on the GPU.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
2026-09-01 18:37:38 +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
                      -- 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

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%