diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 71c093a6..a81a5642 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -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** diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md index fbebc108..a0de6229 100644 --- a/docs/re/METHOD.md +++ b/docs/re/METHOD.md @@ -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. diff --git a/docs/re/data/ptlogo-eff3-rest-vs-oracle.txt b/docs/re/data/ptlogo-eff3-rest-vs-oracle.txt new file mode 100644 index 00000000..5c515c47 --- /dev/null +++ b/docs/re/data/ptlogo-eff3-rest-vs-oracle.txt @@ -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. diff --git a/docs/re/structures/ui-resting-pose.md b/docs/re/structures/ui-resting-pose.md index 72f69999..9d9ac9c3 100644 --- a/docs/re/structures/ui-resting-pose.md +++ b/docs/re/structures/ui-resting-pose.md @@ -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