From 78a29e01fad9bee147ae5ef95ffd072e0de9b96c Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Mon, 31 Aug 2026 06:59:46 +0000 Subject: [PATCH] handoff: the standing ask answered, the title, the sweeps, and my wrong coverage claim ptframe4, pteff21/22/23 and pteff10 are ADDITIVE, measured. They were missing because Canary's vertex dump was capped at two quads, not because the game does not draw them. The title: everything alpha-over except the sweep strips and ptbtn00f, the PRESS (A) plate's focused variant, whose base is not -- which is what the pulse is made of. And ptlogo_back2 / ptlogo_back2eff are alpha-over despite having every surface property the ptframe* elements have, so the obvious generalisation is refuted on the one screen that could test it. The sweeps are on screen on the main menu and move between frames, in two sessions at different phases. And the coverage claim they checked was wrong -- five elements, not one -- with the correction and their 'every button' point both recorded. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v --- docs/port/HANDOFF.md | 83 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index fc993a78..85ee9687 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -25,6 +25,89 @@ delivered. +## ✅ 2026-08-31 (final) — your standing ask, the title, and a coverage claim of mine that was wrong + +**`ptframe4`, `pteff21`, `pteff22`, `pteff23` are ADDITIVE.** So is `pteff10`. +All measured, none inferred. You were right not to take `ptframe4` from the +pattern — but the reason they were missing was mine, not the game's. + +🔴 **They were in a draw all along.** Canary's vertex dump was capped at **8 +vertices = two quads**. `EXTRAS`' 24-index additive batch holds **six**, so the +log printed `pteff20` and `ptframe3` and silently dropped the other four. Cap +raised to 64, screen re-captured: + +| element | quad px | blend | +|---|---|---| +| `pteff20`, `ptframe3`, **`ptframe4`**, **`pteff21`**, **`pteff22`**, **`pteff23`** | one 24-index draw | **ADDITIVE** | +| **`pteff10`** | 819.2 × 720 | **ADDITIVE** | +| `ptmsg2`, `pttitle`, `ptbtn11f`, `ptbtn12`, `ptbtn13`, the focus ring | one 24-index draw | alpha-over | + +🟡 **One flag on `pteff10` before you adopt it.** You measure it as *nearly +exact* under alpha-over, and the game draws it additive. Both can be true for a +dim wholly-semi-transparent glow (max alpha 130) over a dark background, where +the two nearly coincide — but it is the one row here your renderer does **not** +independently corroborate. + +📌 **`pteff10` also needed the resting SCALE to identify at all**: it ships as +409 × 144 and is drawn at **200 % × 500 % = 816 × 720**. My matcher's "try 1× or +2×" rule could not name it at any scale and printed a near miss against something +else — a failure wearing the clothes of an answer. Now it matches on `pivot × 2 × +rest scale` as well as texture size, with the tolerance set to the log's own NDC +print quantisation. + +### The TITLE — and it refutes the obvious generalisation + +| element | blend | +|---|---| +| `ptbase2`, `ptlogo1`, `ptlogo2`, `ptlogo_tm`, `ptcopyright`, **`ptlogo_back2`**, **`ptlogo_back2eff`**, `ptbtn00` | alpha-over | +| the two rotated sweep strips, **`ptbtn00f`** | **ADDITIVE** | + +🔴 **`ptlogo_back2` and `ptlogo_back2eff` are ALPHA-OVER.** They are the title's +frame-shaped elements — large, dark, 94 %/87 % transparent, every surface +property your `ptframe*` have — and the game does **not** draw them additive. So +*"frame-shaped and mostly transparent ⇒ additive"* is dead on the one screen that +could test it. Keep reading the table as per-element facts. + +📌 **`ptbtn00f` is additive and its own base `ptbtn00` is not.** The `PRESS Ⓐ` +plate's highlight is composited additively over its base — that is what the +documented pulse is made of, and a renderer drawing both alpha-over cannot reach +the pulse's peak by any pacing. + +### Your sweep flag: they ARE on screen on the main menu, and they move + +You asked whether my capture retains NDC positions. It does. + +| session | frame | strip A x | strip B x | vertex alpha | +|---|---|---|---|---| +| 1 | 0 | `0.69 … 2.08` | `−0.61 … 1.42` | `EF` / `9A` | +| 1 | 4 | `0.72 … 2.11` | `−0.64 … 1.39` | `F0` / `9C` | +| 1 | 5 | `0.76 … 2.15` | `−0.68 … 1.35` | `F2` / `9D` | +| 2 | — | `0.24 … 1.62` | `−1.67 … 0.36` | `D7` / `C7` | + +NDC spans `[−1, +1]`. **Both strips overlap the screen in every captured frame**, +step ~0.03 NDC (~19 px) per frame in **opposite** directions, and their vertex +alpha ramps with them. Two sessions catch them at different phases, so they +free-run. **The leaf group runs on the main menu — "the game does not draw them +here" is no longer available as an explanation for your phase sweep.** + +⚠️ It does not say they *contribute* much: additive, vertex alpha 0.60–0.95, over +a texture that is overwhelmingly low-alpha. This measures submission and geometry. + +### 🔴 And my coverage claim was wrong — you were right + +The blend page said everything on both screens was covered but for `pteff10`. +Counting your way — a per-draw row **or** a prose row — it was **five, not one**, +and on `EXTRAS` the four extras were exactly the elements you measure as worst. +Corrected in place. Your smaller point lands too: *"every button"* was a class +generalisation in the page that tells you not to make them. It is now five +buttons plus the ring, individually, on the main menu, and `EXTRAS`' buttons +measured separately above. + +### The menu replicates, three sessions + +Runs 2 and 3, separate boots, reproduce the main menu's assignment **draw for +draw**. The "one session" caveat is retired. + ## ✅ 2026-08-31 (later) — **ADDITIVE.** Measured off the GPU. Stop authoring it. `ptframe1`, `ptframe2` and `ptframe3` are drawn with **`RB_BLENDCONTROL0 =