Sylpheed port agent b36dddaeb5 build: key the reference CLI's target dir by the pinned revision
The reference renderer was a revision behind for three consecutive diff runs and
nothing said so.

After the pin bump, `build-reference-cli` reported success at rev 5414db3 and
`verify-screen` showed main_menu jumping 3/255 -> 72/255. The natural reading was
that the port had regressed. It had not: the port was right and the REFERENCE was
stale. The shared CARGO_TARGET_DIR still held a `sylpheed-cli` built from
8b6dbcf, cargo said "Finished in 0.13s" and left it there. A clean target dir
built a binary resolving ptframe1 to (440,108) t=62; the shared one still said
(620,108) t=16.

The old check -- does `screen list` run -- cannot catch this. A stale binary runs
perfectly.

So: build into `$CARGO_TARGET_DIR/reference-cli/$rev`, keyed by the pin, where a
new revision has no artifacts to reuse. Then verify the binary AGAINST export/:
both come from the same pin, so if the CLI resolves ptframe1's rest differently
from what the exporter wrote, the two halves of the verification are not the same
revision and it fails loudly. It compares the two rather than asserting a
literal, so it stays true when the pin moves again.

docker/bin is baked into the image, so this needs an image rebuild to reach
PATH; until then invoke the repo copy by path.
2026-08-28 21:44:08 +00:00

Sylpheed Godot

A clean-room Godot 4 port of Project Sylpheed: Arc of Deception, starting with the menu shell: developer splash → intro video → title → main menu → submenus.

You need your own copy of the game. Nothing in this repository is game content. An offline exporter reads the disc you supply and writes an open, moddable asset tree; the Godot project reads only that tree and never touches a disc format.

  your disc  ──▶  crates/sylpheed-export  ──▶  export/   ──▶  port/  (Godot 4)
                  (Rust; decoders come from      JSON + PNG        reads ONLY
                   sylpheed-formats)             + OGG + OGV       open formats

Why the wall

Two reasons, and the second is the interesting one:

  1. Godot cannot read IPFB archives, RATC bundles, T8aD textures, XMA banks or WMV video, and it should not learn to.
  2. Modding is a goal of this port. If the runtime reads the original formats, modding means reverse engineering. If it reads JSON and PNG, modding means opening a file.

Where the knowledge comes from

The decoders live in sylpheed-formats, pinned by revision — a separate project, where the reverse engineering happens. Its docs/port/HANDOFF.md is the contract: what has been decoded, what was measured off the running game, and what is known to be undecodable. Read it before assuming a value is on the disc.

Layout

crates/sylpheed-export/ disc → open formats. Regenerates export/ wholesale
port/ the Godot 4 project
authored/ decisions that are not on the disc, each with its reason
export/ generated, gitignored, never hand-edited
tools/ verification harnesses that hold the port to the reference renderer
docs/ the mission, the format spec, the agent's loop prompt

Verifying

sylpheed-cli screen render -- built from the same sylpheed-formats revision the exporter is pinned to -- is the reference renderer. tools/verify-screen draws every exported screen both ways and reports the largest per-channel difference in the frame:

tools/verify-screen              # every screen in the manifest
tools/verify-screen main_menu    # one of them

Where the two disagree, one of them is wrong; docs/DECISIONS.md says which and why, rather than tuning the port until the number goes down.

Status

P1. The exporter writes GP_TITLE's twelve screen builds and their sprites, and the Godot project draws any of them statically at 1280x720 from that tree alone. main_menu matches the reference renderer to within 3/255 on every channel of every pixel. Next: P2, keyframe animation.

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%