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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-31 06:59:46 +00:00
parent fa887b4e5f
commit 78a29e01fa

View File

@@ -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.600.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 =