re: EXTRAS complete -- ptframe4, pteff21/22/23 and pteff10 are all ADDITIVE

The four elements the port measured as the worst on EXTRAS, and which appeared
in no draw, were in a draw all along: the 24-index additive batch holds six
quads and Canary printed the first two. Cap raised to 64, screen re-captured,
all six named. Same draw as ptframe3, whose state was already measured -- the
one-way implication doing real work.

pteff10 is identified too, and it needed the resting SCALE: it ships as 409x144
and is drawn at 200 % x 500 % = 816x720. The matcher's 'try 1x and 2x' rule
could not name it at any scale and reported a near miss against something else,
which is a failure wearing the clothes of an answer. Candidates are now the
declaration's pivot*2 scaled by the resting keyframe as well as the texture at
1x and 2x, and the tolerance is the log's own NDC print quantisation rather than
a chosen number.

Flagged rather than buried: pteff10 measuring additive is in tension with the
port measuring it nearly exact under alpha-over. Both can be true for a dim
semi-transparent glow over a dark background, and it is the one row a rendering
check does not corroborate.

Also stated: the three full-screen alpha-over draws are NOT individually
identified -- four elements declare 1280x720 -- so the label on those rows is a
candidate, not an identification.

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:11 +00:00
parent f0b4f0ad5f
commit fa887b4e5f
5 changed files with 389 additions and 29 deletions

View File

@@ -223,3 +223,63 @@ measures submission and geometry, not the light they add. A port whose render
looks worse with them visible has either a placement, a phase or a magnitude
problem — but "the game does not draw them here" is not available as an
explanation any more.
## ✅ 2026-08-31 (final) — `EXTRAS` is COMPLETE, and the four missing elements are ADDITIVE
The four elements the port measured as the worst on `EXTRAS`, and which appeared
in no draw, were in a draw all along. `EXTRAS`' 24-index additive batch holds
**six** quads; Canary's vertex dump printed the first **two**.
[`data/ui-blend-extras-complete.txt`](../data/ui-blend-extras-complete.txt) ·
[`captures/ui-draws/blend-extras-run2-2026-08-31.log`](../captures/ui-draws/blend-extras-run2-2026-08-31.log)
| draw | quad px | element | blend |
|---|---|---|---|
| 7 | 614.4 × 518.4 | `pteff20` | **ADDITIVE** |
| 7 | 243.2 × 219.6 | `ptframe3` | **ADDITIVE** |
| 7 | 256.0 × 212.4 | **`ptframe4`** | **ADDITIVE** |
| 7 | 403.2 × 3.6 | **`pteff21`** | **ADDITIVE** |
| 7 | 422.4 × 7.2 | **`pteff22`** | **ADDITIVE** |
| 7 | 435.2 × 7.2 | **`pteff23`** | **ADDITIVE** |
| 6 | 819.2 × 720 | **`pteff10`** | **ADDITIVE** |
| 8 | 352.0 × 39.6 | `ptmsg2` | alpha-over |
| 8 | 179.2 × 32.4 | `pttitle` | alpha-over |
| 8 | 268.8 × 57.6 | `ptbtn11f` | alpha-over |
| 8 | 249.6 × 43.2 | `ptbtn12` | alpha-over |
| 8 | 108.8 × 43.2 | `ptbtn13` | alpha-over |
**All six are in one draw with `ptframe3`, whose state was already measured**, so
this is the one-way implication doing real work: same draw ⇒ same state.
### `pteff10` is identified, and it needs the resting SCALE
`pteff10` ships as **409 × 144** and is drawn at **200 % × 500 % = 816 × 720**.
The matcher's old "try 1× and 2×" rule could not name it at any scale, and
reported a near miss against something else instead — a failure wearing the
clothes of an answer. Candidates are now the declaration's `pivot × 2` scaled by
the **resting keyframe**, as well as the texture at 1× and 2×, and the tolerance
is the log's own **NDC print quantisation** (two decimals → 6.4 px in x, 3.6 px
in y) rather than a chosen number.
🟡 **And `pteff10` being additive is a live tension worth stating.** The port
measures it as **nearly exact** rendered alpha-over. Both can be true — it is a
dim, wholly semi-transparent glow (max alpha 130) over a dark background, where
additive and alpha-over nearly coincide — but it is the one row of this table
that a rendering check does *not* independently corroborate, and it should be
adopted knowing that.
### What is still not identified, on any screen
* **the two rotated sweep strips** — matched by their AABB, not by a declared
size, because they are rotated nested leaves. The control pins them at 1134 and
1303 px on every screen and the port has an independent 884 px footprint for
the width, so they are identified; the matcher simply cannot do it by size.
* **the focus ring** — drawn at 64.0 × 61.2 against `ptbtneff01`/`02`'s 42 × 46.
It spins and scales, so its AABB is not its sprite size. Alpha-over on both
screens.
* **the three full-screen 1280 × 720 alpha-over draws** — `ptbase`, `pteff05`,
`pteff02.prm` and `pteff00.prm` all declare 1280 × 720, so size cannot separate
them. Two of the three carry a bound texture and one does not, which narrows it
and does not close it. All four candidates are alpha-over, so nothing turns on
it — but the label the tool prints on those rows is **a candidate, not an
identification**.