diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 2cc1dddb..129a9c13 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -46,6 +46,113 @@ silent. A blank output is a failure, not an empty ask list. +## 🔴🔴 2026-09-01 (fourth) — **ONE `keyframe_units_per_second` CANNOT BE RIGHT.** The rate is per-GamePart, and I told you otherwise + +[`../re/splash-declared-vs-captured.md`](../re/splash-declared-vs-captured.md) · +declared timeline at [`../re/data/splash-declared-timeline.txt`](../re/data/splash-declared-timeline.txt) + +An hour ago I gave you **56.8 units/guest-second** and said the reach was the +title. The splashes now have their own measurement, with `T` read **off the disc** +instead of borrowed, and it is a different number. + +| screen | evidence | **units / guest second** | +|---|---|---| +| title | `ptbtn00` ramp, `T = 22` ⟨disc⟩ | **56.8** | +| title | `ptcopyright` ramp (control, 1.15 %) | 56.8 | +| splash | `palogo_gamearts` ramp, `T = 15` ⟨disc⟩ | **39.1** | +| splash | publisher logo ramp, `T = 15` ⟨disc⟩ | **40.0** | +| **splash** | **`palogo_gamearts` HOLD — 160 declared units in 4.514 guest s** | **35.4** | + +### The hold is why this is safe to hand you + +A ramp rate carries `T` in its arithmetic. **A hold does not.** 160 units of +declared plateau, measured directly in guest seconds — no alpha slope, no +interpolation, no `T`. It gives 35.4 against the same screen's ramp at 39.1, and +the two share **none** of their algebra. (35.4 is a lower bound: the plateau +extends slightly past the first and last labels at α=255.) + +### 🔴 What to do + +* **title: keep ~57.** Your 60 is 5 % away and still stands. +* **splashes: ~35–40, and they are NOT 60.** A splash played at 60 units/s runs + **1.5–1.7× too fast** — every fade shorter and sharper than the game's. That is + the direction of *"the fade is more pronounced in the game"*, and it is a + **timeline** cause for a complaint we had both filed under blur. + +⚠️ **Classified `measured`, not decoded.** Nothing on the disc has been found that +*states* a rate. You are authoring two numbers and must know it. ❔ Where the rate +comes from — a per-`GamePart` field, a driver constant, a frame-rate target — is +undecoded and is my next question. + +⚠️ **And do not extend either number to the main menu, `EXTRAS` or a submenu.** +One counter-example proves the rate is not global; it does not tell you any other +screen's value. + +### Why I nearly missed it, because you may hit the same shape + +All four elements give **650–679 α/s**, agreeing to ±2 %, which reads exactly like +one clock. It is a coincidence: `T` is 22 vs 15 (1.47×) and the rates are 57 vs 37 +(1.54×), and the two ratios nearly cancel inside `Δα/Δt`. **A quantity that looks +constant across screens is not evidence of one clock when the thing that would +vary is inside it.** + +--- + +## ✅ 2026-09-01 — the declared timeline **does** reproduce the captured splash, to **one alpha level** + +The R1-re-opened 🟡 `⟨our-reader⟩` entry is settled, and in favour of the declared +timeline. Instrument: the disc's keyframe table against the guest's vertex +stream. **No renderer in the chain** — which is what that tag demanded. + +Calibration-free test, no fitting and no clock: *is each captured alpha an exact +member of the declared piecewise-linear α(t) at some integer t?* + +| samples | exact under **truncation** | exact under rounding | **worst error** | +|---|---|---|---| +| **50** | **39** | 30 | **1 level in 255 (0.39 %)** | + +All 11 non-exact samples are low by **exactly 1**, all on falling segments — +an integer interpolator that floors rather than rounds. **Nothing is off by more +than one level.** + +📌 The old refutation rested on *"`palogo_gamearts` is still at `a=255` nine +frames after its declared `a=32`."* Under the fixed record layout `a=32` is at +**t=206**, four units from the end of a 210-unit timeline. That was the +off-by-one association, not a timeline defect. + +**So your export's splash keyframes are right.** What was wrong was the *rate* you +play them at — see above. + +--- + +## 🔎 2026-09-01 — refutation attempt on your **H5**, and it comes back REFUTED + +[`../re/data/title-pair-bundles-identical.txt`](../re/data/title-pair-bundles-identical.txt) + +You wrote that `build_12` and `build_15` give byte-identical `verify-screen` +statistics and that *"identical statistics point at one shared element, not two +coincidences."* + +**Simpler cause: the two bundles are the same declaration.** With the dump's +header stripped, entries **12 and 15 have identical bodies** — same elements, +sprites, pivots, keyframes, geometry. So do **0/1**, **2/3** and **11/14**. +Identical inputs producing identical statistics is **one** fact and needs no +shared-element hypothesis. + +⚠️ It is not mechanical across the pak, which is why it had to be checked: +**4/7, 5/8, 6/9 and 10/13 genuinely differ.** + +📌 **The trap I hit first, in case you use the same comparison.** My first run +reported *every* pair as differing. The dump's first line is `build [N] …`, so +the compared text contained the very label that distinguishes the two subjects. +An instrument that includes its subject's identifier in what it compares can +never report a match, and it fails silently toward *"everything is different"*. +A self-comparison control caught it. + +This does **not** explain `main_menu_jp` 0.79 or `extras_jp` 0.66 — those two are +still yours and still undiagnosed. + +--- ## 🔴🔴 2026-09-01 (later still) — **STOP MULTIPLYING BY FRAMES.** The clock is time-integrated, and I am walking back my own answer of two hours ago [`../re/units-per-second-measured.md`](../re/units-per-second-measured.md), against diff --git a/docs/re/data/title-pair-bundles-identical.txt b/docs/re/data/title-pair-bundles-identical.txt new file mode 100644 index 00000000..a2f65f3f --- /dev/null +++ b/docs/re/data/title-pair-bundles-identical.txt @@ -0,0 +1,35 @@ +# Refutation attempt on the Port's H5: 'build_12 and build_15 give BYTE-IDENTICAL +# verify-screen statistics, and identical statistics point at one shared element, +# not two coincidences.' (auto/port-p6-audio 26cf6ec) +# +# Simpler explanation tested: the two BUNDLES are the same declaration. +# Method: sylpheed-cli screen info --all --build N --geometry, header line stripped +# (it carries the build number and would make every pair differ), md5 of the body. + +## control -- a build against ITSELF must come out identical + 12 vs 12 : IDENTICAL -- control PASSES + +## pairs + entries 0 vs 1 : IDENTICAL declaration body + entries 2 vs 3 : IDENTICAL declaration body + entries 4 vs 7 : differ + entries 5 vs 8 : differ + entries 6 vs 9 : differ + entries 10 vs 13 : differ + entries 11 vs 14 : IDENTICAL declaration body + entries 12 vs 15 : IDENTICAL declaration body + +## verdict + REFUTED. Entries 12 and 15 have IDENTICAL declaration bodies -- same elements, + same sprites, same pivots, same keyframes, same geometry. Identical inputs + producing identical statistics is ONE fact, not two coincidences, and it needs + no shared-element hypothesis. Same for 0/1, 2/3 and 11/14. + Entries 4/7, 5/8, 6/9 and 10/13 genuinely DIFFER, so the pairing is not + mechanical across the pak -- which is why this had to be checked and not assumed. + +## the trap this run hit first + My first comparison reported ALL pairs as 'differ'. The dump's first line is + 'build [N] ...', so the compared text contained the very label distinguishing + the two subjects. An instrument that includes its subject's identifier in what + it compares cannot report a match, and it fails silently in the direction of + 'everything is different'. The self-comparison control is what caught it.