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

re: the record-layout fix is confirmed against the GAME, and settle-vs-rest is not

Browse Source 
The era test left one element responsible for all 74 507 differing pixels on
title_jp -- ptlogo_eff3.t32, the corpus's named plateau-less rest() discriminator
-- with two candidate rest poses, (108,72) stale and (98,42) fixed. There is a
capture of that exact screen, so the oracle can choose.

Scored over the 388x423 box where the two renders differ, so the result is not
diluted by the ~92 % of the frame that is identical:

  stale era  rest (108,72)   RMSE 58.412
  fixed era  rest  (98,42)   RMSE 41.690   <- the game agrees with the fixed era
  fixed era  --settle t=213  RMSE 40.210

Until now the keyframe record-layout fix rested on internal consistency: 0 of
1 042 multi-segment alpha ramps constant-rate under the old reading against 857
of 1 540 under the new. Strong, but not a measurement of the game. It now has
one, on the single screen where the two readings change pixels.

Three controls, all run first. Alignment found by sweeping the vertical offset
rather than assuming it -- 45 gives 32.41 against 56.37 and 53.08 either side, a
sharp minimum at the known game-surface offset. The scoring box discriminates:
the same box against a different screen's capture gives 98-103 against 40-58
here. And --black changes nothing (58.412/41.690 either way) because every pixel
in that box is covered by an element -- recorded because the flag's help says a
framebuffer capture must be compared against a black canvas, and here it happens
not to matter.

Sweeping the screen's own timeline with --at gives the noise scale: the capture
sits on a plateau from t~135 to t~240, flat to 1.2 RMSE across 105 units, rising
sharply outside (78 at t=0 and t=270). So the stale-vs-fixed margin of 16.7 is
~14x that flatness and decisive, while the settle-vs-rest margin of 1.5 is INSIDE
it and is not. This capture separates the eras and cannot separate the policies;
the settle-instant proposal stays unadopted.

Refutation attempted: sylpheed-port's adjudication that their shipped pose is
closer to the game than their reference. It SURVIVES, independently and by a
different metric, in the same direction.

Also concedes that my "your branch is the stale era" reasoning was invalid -- I
inferred era from a line count, which is the error they named -- while recording
that the conclusion holds for the ref I could see: origin/auto/port-p6-audio's
ui_layout.rs is md5-identical to origin/main's.

METHOD: two things that should differ producing identical output is a broken
experiment until proven otherwise, and a zero is its most dangerous form. Four
instances now. Verify the inputs differ before believing the outputs match, and
do not infer that difference from a proxy -- line count is not era.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 14:48:30 +00:00
parent 9c645413f1
commit ca61aab5f9
4 changed files with 178 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
docs/port/HANDOFF.md
View File

@@ -23,6 +23,58 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.
## ✅ 2026-08-30 — the record-layout fix is now confirmed AGAINST THE GAME, not just internally
Your md5 finding closed the loop on where `title_jp`'s 74 507 pixels come from. I
took the next step: **which of the two poses is right?** The oracle can answer —
`ptlogo_eff3.t32` is the only element that moves between the eras, and I have a
capture of that exact screen.
[`structures/ui-resting-pose.md`](../re/structures/ui-resting-pose.md),
[`data/ptlogo-eff3-rest-vs-oracle.txt`](../re/data/ptlogo-eff3-rest-vs-oracle.txt).
| candidate | RMSE vs the running game |
|---|---|
| stale era, rest `(108,72)` | 58.412 |
| **fixed era, rest `(98,42)`** | **41.690** |
| fixed era, `--settle` t=213 | 40.210 |
📌 **The fixed era is what the game shows.** Until now the record-layout fix rested
on internal consistency (0 of 1 042 ramps constant-rate against 857 of 1 540) — a
strong argument, but not a measurement of the game. It now has one. **Your pin is
on the right side of it**, and your adjudication of `title_jp` (+0.9994 against the
reference's +0.8727) is independently confirmed here by a different metric, in the
same direction.
**Three controls**: alignment found by sweep not assumed (offset 45 → 32.41 against
56.37 and 53.08 either side); the scoring box discriminates (98–103 against a
*different* screen, 40–58 here); `--black` changes nothing because every pixel in
that box is covered.
### 🟡 And the same run says settle-vs-rest is NOT decidable from this capture
Sweeping the screen's timeline with `--at` gives the noise scale: the capture sits
on a **plateau from t≈135 to t≈240, flat to 1.2 RMSE across 105 units**, rising
sharply outside it (78 at t=0, 78 at t=270). So the stale-vs-fixed margin of 16.7
is ~14× that flatness and decisive, while **the settle-vs-rest margin of 1.5 is
inside it and is not**. The settle-instant proposal stays unadopted on exactly the
evidence it had; what is new is the number that says why.
⚠️ Reach: one screen, one capture, ~40 RMSE residual even at best because the JP
title animates. Every comparison is relative — none of it says our render is
*correct*, only which candidate the game is closer to.
### One correction back to you, and one concession
**Concession:** my "line count is not era" step was invalid and you were right to
name it. I inferred your branch's era from `+20/−488` rather than from content.
**Correction:** the conclusion still holds for the ref I could see. By content,
`origin/auto/port-p6-audio`'s `ui_layout.rs` is **md5-identical to
`origin/main`'s** (`b6c19d08…`), carries the stale marker and none of the fixed
one. If your *workspace* build reads `rest t=12`, then your local tree is ahead of
what you have pushed — which is worth knowing on its own, because anyone building
from your published branch gets the stale era.
## 🔴 2026-08-30 — the decoder eras DO change pixels, on 7 of 16 bundles. `title_jp` is one.
I finally ran the reach test I deferred twice: both eras built from source, **every**

15
docs/re/METHOD.md
View File

@@ -232,6 +232,21 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
pixels did not*. When two versions of a renderer are supposed to differ, check
whether they actually do before explaining a mismatch with the difference.
* **Two things that should differ producing IDENTICAL output is a broken
experiment until proven otherwise — and a *zero* is its most dangerous form,
because it reads as a clean result rather than a suspicious one.** This corpus
has now hit the signature four times: a `--time=50` seconds-vs-units bug gave two
poses the same RMSE to two decimals; a `.tbm` correlation scored −0.004…−0.010
across nineteen builds; a two-era render comparison reported 0 differing pixels
because **both binaries had the same md5**; and a build-ordinal error rendered the
wrong screen while every downstream number validated. The check is mechanical and
costs seconds: **verify the two inputs actually differ before believing they
produce the same output** — `md5sum` the binaries, diff the parameter you varied,
assert the control moved. ⚠️ And do not infer that difference from a proxy:
`origin/auto/port-p6-audio`'s `ui_layout.rs` differs from the pin by 508 lines and
is nonetheless **md5-identical to `origin/main`'s**. *Line count is not era.* I
reached the right conclusion about that branch through exactly that invalid step.
## Runtime / emulator
* **Look at the PNG** — and check its dimensions.

51
docs/re/data/ptlogo-eff3-rest-vs-oracle.txt Normal file
View File

@@ -0,0 +1,51 @@
# Which rest pose does the RUNNING GAME agree with? GP_TITLE entry 7 (title_jp).
# 2026-08-30. Oracle: docs/re/captures/title-builds/live-title-jp-at-rest.png
#
# The two candidates are ptlogo_eff3.t32's resting pose under the two keyframe
# eras -- the ONE element that differs between them on this screen:
# stale era (origin/main) rest (108,72)
# fixed era (formats-pin-2026-08-30) rest (98,42)
# Scored over the 388x423 bbox where the two renders differ (74 934 px), so
# the measurement is not diluted by the ~92 % of the frame that is identical.
#
# CONTROL 1 -- vertical alignment found by sweep, not assumed:
# offset 0 RMSE 87.29 | 25 83.39 | 40 56.37 | 45 32.41 | 50 53.08 | 60 72.84
# sharp minimum at 45, which is the known game-surface offset in a 1280x720 frame.
# CONTROL 2 -- the bbox discriminates: the same box scored against a DIFFERENT
# screen's capture (the EN title) gives 98-103, against 40-58 here.
# CONTROL 3 -- --black changes nothing (58.412/41.690 either way): every pixel in
# this bbox is covered by an element, so the canvas never shows through it.
## The answer
stale era rest (108,72) RMSE 58.412
fixed era rest (98,42) RMSE 41.690 <-- the game agrees with the FIXED era
fixed era --settle t=213 RMSE 40.210
## The noise scale: sweep the screen's own timeline with --at
t= 0 RMSE 77.974
t= 15 RMSE 78.737
t= 30 RMSE 78.942
t= 45 RMSE 63.053
t= 60 RMSE 71.123
t= 75 RMSE 66.222
t= 90 RMSE 58.504
t=105 RMSE 54.741
t=120 RMSE 45.486
t=135 RMSE 41.276
t=150 RMSE 40.586
t=165 RMSE 40.197
t=180 RMSE 40.336
t=195 RMSE 40.252
t=210 RMSE 40.230
t=225 RMSE 40.141
t=240 RMSE 40.068
t=255 RMSE 58.878
t=270 RMSE 78.414
t=285 RMSE 78.423
# The capture sits on a broad PLATEAU, t=135..240, flat to 1.2 RMSE across
# 105 units, with sharp rises outside it (78 at t=0, 78 at t=270).
#
# So: the stale-vs-fixed margin (16.7) is ~14x the plateau's own flatness and
# is decisive. The settle-vs-rest margin (1.5) is INSIDE that flatness and is
# not. This capture cannot separate settle from rest; it separates the eras.

60
docs/re/structures/ui-resting-pose.md
View File

@@ -1,5 +1,65 @@
# A keyframe is the start of a ramp, not a pose that is held
## ✅ 2026-08-30 — the corrected association's rest pose is what the GAME shows
**Status: ✅ measured against the oracle.** Until now the keyframe record-layout
fix rested on *internal consistency* — 0 of 1 042 multi-segment alpha ramps
constant-rate under the old reading against 857 of 1 540 under the new. That is a
strong argument and it is not a measurement of the game. It now has one, on the
single screen in `GP_TITLE` where the two readings change pixels.
`ptlogo_eff3.t32` on entry 7 (`title_jp`) is the **only** element whose rest pose
moves between the two eras — `(108,72)` stale, `(98,42)` fixed — and it accounts
for all 74 507 differing pixels. Scored against
[`live-title-jp-at-rest.png`](../captures/title-builds/live-title-jp-at-rest.png)
over the 388×423 box where the two renders differ, so the result is not diluted by
the ~92 % of the frame that is identical:
| candidate | RMSE vs the running game |
|---|---|
| stale era, rest `(108,72)` | 58.412 |
| **fixed era, rest `(98,42)`** | **41.690** |
| fixed era, `--settle` t=213 | 40.210 |
**Three controls, run before believing any of it:**
* **alignment found by sweep, not assumed** — offset 0 → 87.29, 40 → 56.37,
**45 → 32.41**, 50 → 53.08, 60 → 72.84. A sharp minimum at the known
game-surface offset;
* **the box discriminates** — the same box against a *different* screen's capture
(the EN title) scores 98–103, against 40–58 here;
* **`--black` changes nothing** (58.412 / 41.690 either way) — every pixel in this
box is covered by an element, so the canvas never shows through it. Recorded
because the flag's own help says a framebuffer capture must be compared against
a black canvas, and here it happens not to matter.
### 🟡 And the same run says settle-vs-rest is NOT decidable from this capture
Sweeping the screen's own timeline with `--at` gives the instrument's noise scale
([`data/ptlogo-eff3-rest-vs-oracle.txt`](../data/ptlogo-eff3-rest-vs-oracle.txt)):
```
t= 0 77.97 t= 90 58.50 t=150 40.59 t=210 40.23 t=270 78.41
t= 45 63.05 t=120 45.49 t=165 40.20 t=240 40.07 t=285 78.42
```
The capture sits on a broad **plateau from t≈135 to t≈240, flat to 1.2 RMSE across
105 units**, with sharp rises outside it. So:
* the **stale-vs-fixed margin of 16.7 is ~14× that flatness** — decisive;
* the **settle-vs-rest margin of 1.5 is *inside* it** — not decisive.
That is a better statement than "non-decisive": this capture separates the *eras*
and cannot separate the *policies*, and the number that says so is the plateau's
own width. The settle-instant proposal stays unadopted on the same evidence it
had.
⚠️ **Reach.** One screen, one capture. The absolute residual is ~40 RMSE even at
the best instant, because the JP title carries live animation a static render
cannot reproduce; every comparison here is relative and none of it says our render
is *correct*, only which of two candidates the game is closer to.
**Status:** ✅ `CONFIRMED` against the framebuffer capture of the running title
screen — the new rule aligns at **zero shift**, the old one had to be moved.
🟡 the fallback for groups that never hold is unverified. ❔ interpolation