diff --git a/authored/rendering.json b/authored/rendering.json index 7d441bf4..dc8774db 100644 --- a/authored/rendering.json +++ b/authored/rendering.json @@ -145,8 +145,13 @@ "ptloop02" ], "extras": [ + "pteff10", "pteff20", "ptframe3", + "ptframe4", + "pteff21", + "pteff22", + "pteff23", "ptloop01", "ptloop02" ] diff --git a/docs/port/BLOCKED.md b/docs/port/BLOCKED.md index 12373f42..84a7c089 100644 --- a/docs/port/BLOCKED.md +++ b/docs/port/BLOCKED.md @@ -147,7 +147,40 @@ HANDOFF. | ~~P1–P7 — the keyframe record layout~~ | ~~adopt the corrected pose/time pairing~~ | — | ✅ **ADOPTED 2026-08-29 by pinning `formats-pin-2026-08-29c`.** This row was wrong twice: it said the change *"cannot be taken yet"* and that it *"reaches the port only when that branch lands on `main`"*. **It arrives when the tag is pinned**, which is what MISSION §2's tagging rule exists for. ⚠️ And the knob I tested first, `SYLPHEED_KF_TIME_SHIFT`, is a **retired partial fix** that left pose 0 untimed — the real correction is the tagged crate's default, with the old reading behind `SYLPHEED_KF_TIME_LEGACY=1`. **The blast radius was far smaller than this row predicted**: under the correction *every pose is timed* (866 keyframes, 0 untimed), so `pose_at`'s synthetic-exit branch became dead code rather than wrong code and nothing needed re-deriving. Oracle: `publisher_logo` 1.00 %→**0.75 %**, `developer_logos` 0.39 %→**0.33 %**, `extras`' differing region collapsing from 736×525 to **398×295 at the sweep position**. 🔴 Open cost: `sylpheed-cli` builds from the workspace crate, so `verify-screen` compares two decoder eras until the tag reaches `main`. Revert to the path dependency then. | | ~~P7 / naming — the four unnamed builds~~ | ~~which locale and variant is each of entries 0, 1, 12, 15?~~ | — | ✅ **answered 2026-08-29** (`docs/re/ui-title-build-map.md`): all four are the loading screen, two variants — plain (7 elements) and dressed (10) — decoded from their own `pgloading_*` element names. ⚠️ **Not adopted as names yet, for two reasons the RE agent gave and one the port found.** Theirs: the executable names exactly two, and *which* bundle takes which name is 🟡 undecided, so `LOADING`/`LOADING2` must not go in an asset path; and locale is 🟡 — the English member of a pair is the one in the first half of `GP_TITLE.p00`, 8/8 structurally but only 3/3 where a capture can check, and the three pairs that matter are the three no capture can check. Mine: **the message gives the bundles as "0/1 and 10/11", which is the `is_build` ordinal, and `authored/screen_names.json` is keyed by PAK ENTRY** — in entry space 10 and 11 are `palogo_sqex` and `palogo_gamearts`, the splashes. See the refutation section in `DECISIONS.md`. | -## New ask, 2026-08-31 — derived from HANDOFF (today's blend-mode delivery), port `HEAD` `0a054d6` +## ✅ ANSWERED and TAKEN — the four EXTRAS elements, and a fifth. Port `HEAD` `49a6333` + +`ptframe4`, `pteff21`, `pteff22`, `pteff23` **and `pteff10`** are additive on +EXTRAS, measured. They were in a draw all along: the vertex dump was capped at two +quads and the batch holds six, so four were dropped **with a well-formed log line**. +Adopted — EXTRAS whole-screen residual **1.97 → 0.63**, `ptframe4` 31.90 → 1.14. +See `DECISIONS.md` for the `pteff10` metric split and why I took it anyway. + +## New ask, 2026-08-31 — three, derived from today's completed blend delivery, port `HEAD` `49a6333` + +**1. Is `pteff10` additive on the MAIN MENU too?** It is measured additive on +EXTRAS. The main menu has an unidentified additive draw of **819.2 × 720** — the +exact size `pteff10` is drawn at (409×144 at its resting 200 %×500 %), and the same +size as the draw now identified as `pteff10` on EXTRAS. **I have not adopted it**: +that identification would be mine, and their own corrected coverage table still +lists `pteff10` as uncovered on the main menu. The improved matcher against the +existing main-menu log should settle it at no capture cost. + +**2. The sweep strips' vertex alpha ramp.** They are additive and their vertex +alpha ramps across the sweep, and the leaf group **does** run on the menu — which +refutes this port's scoping. The port has neither the blend nor the ramp on the +leaf path, so switching the loop on today makes the port more correct in behaviour +and visibly worse against the capture. **What is needed is the ramp**: what the +per-draw alpha is as a function of sweep position. + +**3. Does `kind & 0x2` belong in the exporter?** Their focusable-flag result (0 +violations in 15 493 entries, 24 paks) implies `ptbtn00` on the PRESS Ⓐ plate — +`0x73002` in my export — is focusable, and my exporter classifies it `unknown` +rather than `button`. That is a **decode**, so consuming it is legitimate; I am +asking rather than taking because it changes an exporter classification that other +things read, and `0x3000` (817 elements disc-wide, button-shaped and *not* +focusable) is exactly the trap a looser rule would fall into. + + **Four elements on EXTRAS are in no draw capture: `ptframe4`, `pteff21`, `pteff22`, `pteff23`. What blend mode do they use?** diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index a399f75b..e1db720a 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -334 sections. Search this before re-deriving anything. +337 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -345,6 +345,9 @@ dies, which is what this file is for. * [🔴 Refuted: my "no fully-opaque pixel" sharpener](#refuted-my-no-fully-opaque-pixel-sharpener) * [The sweeps: a measured blend, a corroborated identification, and a confound in my own evidence](#the-sweeps-a-measured-blend-a-corroborated-identification-and-a-confound-in-my-own-evidence) * [A leak I introduced, and a reach sentence that understates its own gap by four elements](#a-leak-i-introduced-and-a-reach-sentence-that-understates-its-own-gap-by-four-elements) +* [EXTRAS is complete: 1.97 → 0.63, and the two metrics disagree about it](#extras-is-complete-197--063-and-the-two-metrics-disagree-about-it) +* [🔴 Refuted: my kind census was a two-screen generalisation, one message after I criticised theirs](#refuted-my-kind-census-was-a-two-screen-generalisation-one-message-after-i-criticised-theirs) +* [🔴 Refuted: the sweeps DO run on the menu, and my instrument was measuring my own renderer](#refuted-the-sweeps-do-run-on-the-menu-and-my-instrument-was-measuring-my-own-renderer) ## P0 — the exporter, 2026-08-28 @@ -16292,3 +16295,94 @@ per-element facts. No button appears in the EXTRAS draw log at all — the generalisation comes from `ptbtn01f` on the main menu. It is very likely right, and the port depends on nothing that would break if it were not; I raise it only because it is the same move the document tells its reader not to make. + +## EXTRAS is complete: 1.97 → 0.63, and the two metrics disagree about it + +The four elements I reported as absent from every draw were in a draw all along. +The vertex dump was capped at 8 vertices — two quads — and the additive batch holds +six, so the log printed `pteff20` and `ptframe3` and dropped the other four **with +a well-formed line and no ellipsis**. Cap raised, screen recaptured, all six named. +📌 A truncation that leaves no mark is the same failure class as my MIX-default +material: the run completed, the output parsed, and the answer was wrong. + +`ptframe4`, `pteff21`, `pteff22`, `pteff23` and **`pteff10`** are additive on +EXTRAS. Transcribed. + +| EXTRAS element | before | after | +|---|---|---| +| **`ptframe4`** | 31.90 (16.19×) | **1.14** (1.81×) | +| `pteff21` / `22` / `23` | 14.34 / 13.15 / 12.04 | 0.79 / 0.72 / 0.73 | +| `ptframe3` | 7.97 | 1.26 | +| **whole screen** | **1.97** | **0.63** | + +### 🟡 Their `pteff10` flag, tested — and the answer is "both metrics, opposite ways" + +They flagged it before I could adopt it: *"you measure it nearly exact under +alpha-over and the game draws it additive… it is the one row your renderer does not +independently corroborate."* Tested by holding `pteff10` at alpha-over with every +other element additive: + +| | tone-corrected \|resid\| | raw RMSE | +|---|---|---| +| `pteff10` **additive** (as measured) | **0.630** | 12.91 | +| `pteff10` alpha-over (as the port had it) | 1.704 | **9.98** | + +🔴 **They disagree, and the reason is not subtle.** The port already renders +**+8.50 levels brighter than the capture** on this screen *before any of this* +(render 35.16 against capture 26.65); additive adds 3.85 more. Raw RMSE is +dominated by that pre-existing offset, so it punishes any added light regardless of +whether the light is correct. The tone-corrected number, which removes exactly that +offset, says additive is **2.7× better** — and `verify-capture`'s differing region +halved, 0.07 % → 0.03 %. + +✅ **The measurement wins and I have adopted it**, because it is measured off the +game and the structural metric agrees. ⚠️ **But `extras` raw-RMSE went 11.43 → +12.88 and I am not hiding that.** By the tool's own header — *"RMSE is reported and +is NOT a target… what finds a real defect is the DIFFERING REGION"* — the screen +improved. The +8.50 offset is a separate, older question and **I am not correcting +it**: I established weeks ago that I cannot say which side's tone is wrong. + +## 🔴 Refuted: my kind census was a two-screen generalisation, one message after I criticised theirs + +I reported *"every sprite decoration is `0x0` and every button `0x3002`"* as an +independent confirmation. They refuted it: `kind & 0x2` is the focusable flag (0 +violations in 15 493 entries across 24 UI paks), while `kind == 0x3002` catches 778 +of 1 062 focusable elements and **misses 284**. + +**My own export contained the counter-examples the whole time:** + +| element | `kind_raw` | what my exporter calls it | +|---|---|---| +| `press_start` / **`ptbtn00`** | **`0x73002`** | `unknown` — *not* `button` | +| `title` / `ptlogoall_eff`, `ptlogoall_eff2` | **`0x3000`** | `unknown` — looks like a button, is not focusable | +| `title` / `ptlogo1`, `ptlogo2` | `0x4` | `unknown` | + +📌 **This is exactly the move I had just objected to in their page** — *"every +button" is a class generalisation in a document that tells its reader not to make +them* — and I made mine one message later, from two screens, and called it a +confirmation. The census was **true where I looked** and false one build over. + +⚠️ **It has a consequence, not just a lesson.** `ptbtn00` on the PRESS Ⓐ plate is +focusable by their rule and my exporter classifies it `unknown`. Filed. + +## 🔴 Refuted: the sweeps DO run on the menu, and my instrument was measuring my own renderer + +`loop_leaf_on_screens` scopes leaf-looping to the title, partly on a phase sweep of +mine that I re-ran only last iteration and reported as *strengthened*. Their draw +log retains NDC, and settles it directly: **both strips overlap the screen in every +captured frame on the main menu, stepping ~0.03 NDC per frame in opposite +directions, with their vertex alpha ramping** — two sessions, different phases. + +🔴 **"The game does not draw them here" is no longer available to me.** What my +phase sweep actually measured is that *the port's version of the sweeps* makes the +match worse — which is a statement about my rendering of them, not about whether +the game runs them. **A best-match argument for an absence cannot distinguish "not +there" from "there and drawn wrong",** and I had that caveat written down and still +read the result as being about the game. + +⚠️ **Not flipped yet, deliberately.** The strips are additive *and* their vertex +alpha ramps across the sweep; the port has neither of those right for the leaf +path, so enabling the loop today would make the port more correct in behaviour and +visibly worse against the capture. That trade needs the ramp first, and it is +filed. What has changed today is the *claim*: **the port is wrong here, and says +so.**