fabi/Sylpheed-Godot
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

deps: bump the pin to f817dd5 -- the menu screens get their background

Browse Source 
WHAT I WANTED FROM IT: 56cc7ac, "a RATC child's name is stated, not inferred".
A child was named by scanning backwards for the last printable run of bytes
before its magic. For `pteff05.t32` the three trailing payload bytes are
38 41 58 = `8AX`, which beat the real name, so the child registered under a name
no element declares and resolved to no sprite.

`pteff05.t32` is the full-resolution background of all five menu screens.

Every menu render this port has produced has been missing its background, and
P1 wrote that up as a fact about the disc -- "the bundle carries zero RATC
children for either, so there is no texture on the disc to export". That is
retracted in docs/DECISIONS.md rather than edited away.

The re-export is contained: six new sprites and nothing else. pteff05 on
main_menu/extras and their JP twins, pteff04 on both titles. Each gains a
`sprite` line and moves `layer_source` from "implied" to "sprite" -- the layer
key is now read from the file instead of the decoders' table of keys measured
off the running game, which is the ratchet turning the right way.

pteff05.png is 1280x720; ptbase.png, which had been carrying the background
alone, is 640x360 drawn at 200 %.

Measured against the live capture rather than the other renderer: settled
main_menu RMSE 8.05 % -> 5.92 %. The reference renderer was missing the same
element for the same reason, so no renderer-vs-renderer diff could have found
this -- the third time a capture has caught something both renderers agreed on.
This commit is contained in:
Sylpheed port agent
2026-08-29 08:04:06 +00:00
parent 4a5fa7f1cb
commit f6fccee11c
3 changed files with 79 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
docs/DECISIONS.md
View File

@@ -266,12 +266,10 @@ texture", because both renderers use the declared pivot. That prediction held:
the port and the CLI agree on every scaled element, and that agreement is **not
evidence** about which anchor the game uses. It stays open.
### `pteff05.t32` and `pteff04.t32` have no sprite, and that is correct
### ~~`pteff05.t32` and `pteff04.t32` have no sprite, and that is correct~~
Both renderers skip them. The bundle declares them and carries **zero** RATC
children for either, so there is no texture on the disc to export — this is a
property of the disc, not a gap in the exporter, and `ScreenView` reports it as
`no sprite in the export` rather than dropping it silently.
**RETRACTED 2026-08-29. This was wrong, and it was the most consequential thing
on this page.** See "The menu had no background" below.
---
@@ -502,3 +500,66 @@ their diagnoses stand — a paint-order tie, two pixels, and nearest-neighbour
sampling phase at 125 % scale. The title's swoosh defect the RE agent localised
(drawn thick and white where the game draws it thin and pink) is untouched by
any of this and remains P3's.
---
## The menu had no background, and P1 called that correct, 2026-08-29
The pin moved `5414db3 → f817dd5` for `56cc7ac`, "a RATC child's name is stated,
not inferred". `ratc::parse` had named each child by scanning backwards for the
last printable run of bytes before its magic. For `pteff05.t32` the three
trailing payload bytes are `38 41 58` — `8AX` — which beat the real name, so the
child registered under a name no element declares and resolved to no sprite.
`pteff05.t32` is the **full-resolution background of all five menu screens**.
So every render this port has produced of a menu screen has been missing its
background, and P1 wrote that up as a property of the disc: *"the bundle declares
them and carries zero RATC children for either, so there is no texture on the
disc to export."* That sentence was false. The bundle carries the child; the
decoder was handing back the wrong name for it. Retracted above rather than
edited away.
### What the re-export shows
Six new sprites and nothing else: `pteff05.png` on `main_menu`, `extras` and
their Japanese twins, `pteff04.png` on both titles. Per screen the JSON gains a
`sprite` line and `layer_source` moves `"implied" → "sprite"` — the layer key is
now **read from the file** instead of taken from the decoders' table of keys
measured off the running game. That is the derived/authored ratchet turning the
right way, in the exporter rather than in `authored/`.
`pteff05.png` is **1280×720**; `ptbase.png`, which had been carrying the
background alone, is 640×360 drawn at 200 %. The screen was being shown its own
art at half resolution.
### Measured against the live capture, not against the other renderer
Whole-frame RMSE of the settled `main_menu` against
`captures/main-menu-oracle.png`:
| | RMSE |
|---|---|
| before this pin | 8.05 % |
| with the real background | **5.92 %** |
A 26 % reduction, and it is the right kind of evidence: the reference renderer
was missing the same element for the same reason, so a renderer-vs-renderer diff
could not have found this. It is the third time on this project that the
capture caught something both renderers agreed on — the bracket, the title dim
quad, and now the background.
`verify-screen` after the bump is unchanged in character: everything at 3–4/255
except `title` (6, the paint-order tie) and `title_jp` (155, the sampling phase).
Both renderers gained the background together.
### One thing the comparison says that I did not expect
Rendering with `--focus=ptbtn01`, which is how the capture was taken, makes the
RMSE **worse** — 5.92 % → 7.00 %. The port *replaces* an element's sprite with
its `*f` twin; `sylpheed-cli`'s own `--focus` is documented as drawing the
focused record **over** the base element. Those are different operations, and
the capture shows a ring marker beside `NEW GAME` that the port does not draw.
This is P5's, not P2's, and it is not being guessed at here. Raised in
`docs/BLOCKED.md`.