From 975d77f0b28497eddb5da3a7267b8e09d7d1fd16 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Mon, 31 Aug 2026 07:06:18 +0000 Subject: [PATCH] port: take the completed EXTRAS blend set, and record two refutations that land on me EXTRAS whole-screen residual 1.97 -> 0.63; ptframe4 31.90 -> 1.14, pteff21/22/23 from 12-14 to under 0.8. The four elements I reported as in no draw 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 line and no ellipsis. Same failure class as my MIX-default material: the run completed, the output parsed, the answer was wrong. Their pteff10 flag, tested by holding it alpha-over with everything else additive: tone-corrected residual 0.630 additive against 1.704 alpha-over, but raw RMSE 12.91 against 9.98. They disagree because the port already renders +8.50 levels brighter than the capture on this screen before any of this, so raw RMSE punishes added light whether or not the light is right. Adopted on the measurement plus the structural metric; extras raw-rmse went 11.43 -> 12.88 and that is stated, not hidden. The differing region halved, 0.07 % -> 0.03 %. Refuted, mine: "every decoration 0x0 and every button 0x3002" was a two-screen generalisation I called a confirmation, one message after objecting to exactly that move in their page. My own export held the counter-examples -- ptbtn00 is 0x73002 and my exporter calls it unknown rather than button; three title elements are 0x3000, button-shaped and not focusable. kind & 0x2 is the focusable flag. Refuted, mine: the sweeps DO run on the main menu. Their log retains NDC and both strips overlap the screen in every captured frame, stepping in opposite directions with vertex alpha ramping. My phase sweep measured that the PORT'S sweeps make the match worse, which is a statement about my rendering, not about the game. A best-match argument for an absence cannot separate "not there" from "there and drawn wrong", and I had that caveat written down and read past it. Not flipped: the strips are additive with a ramping vertex alpha and the port has neither on the leaf path, so enabling the loop today would be more correct in behaviour and worse on screen. The ramp is asked for. What changed today is the claim -- the port is wrong here and now says so. --- authored/rendering.json | 5 +++ docs/port/BLOCKED.md | 35 ++++++++++++++- docs/port/DECISIONS.md | 96 ++++++++++++++++++++++++++++++++++++++++- 3 files changed, 134 insertions(+), 2 deletions(-) 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.**