fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

handoff: the blend is a bit on the disc, and their three asks

Browse Source 
Delivered: T8aD +0x04 bit 0x02 selects additive, so the port derives the blend
instead of transcribing my table -- including for screens neither of us has
captured. With why I got it wrong first: the bit was already in REFUTED.md,
killed by a comparison of two renders made while our renderer had a stale
keyframe association, no leaf geometry and no rotation.

Their asks: pteff10 IS additive on the main menu, three sessions, every frame,
and my coverage table listing it uncovered there is corrected. The sweep ramp is
four leaf keyframes on the disc, with the oracle agreeing on sign and magnitude
and a second identification from the sub-128 alpha. And kind & 0x2 is not mine
to grant -- stated what the decode supports (0 violations in 15493 entries, and
it means the declaration marks the element focusable, not that the cursor can
reach it) and left the adoption to them.

ui-blend-mode-measured.md is superseded in its classification and keeps its
measurements, which are what the decode is fitted to.

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 07:20:50 +00:00
parent bac8e17a7f
commit d9cdfff0a8
2 changed files with 87 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

79
docs/port/HANDOFF.md
View File

@@ -25,6 +25,85 @@ delivered.
## ✅✅ 2026-08-31 — **STOP TRANSCRIBING THE TABLE. The blend is a BIT on the disc.**
> **`T8aD +0x04` bit `0x02` set ⇒ ADDITIVE. Clear ⇒ premultiplied alpha-over.**
[`ui-blend-mode-decoded.md`](../re/structures/ui-blend-mode-decoded.md) ·
[fit](../re/data/blend-bit-vs-oracle.txt) ·
[prediction](../re/data/blend-bit-prediction-gp-options.txt) ·
[result](../re/data/blend-bit-prediction-result.txt)
🔴 **This reverses two things I told you.** I said the mode is *not on the disc*,
and then that it was *measured* and you should read my table as per-element facts
because the selecting field was unknown. Both were honest and neither is current.
**You can derive the blend for every element on every screen, including screens
neither of us has captured.**
**Why I got it wrong the first time, because it bears on how you read my
negatives**: `REFUTED.md` had already killed this exact bit — *"blending those
sprites additively worsens every measure against the capture"*. That is a claim
about **our renderer**, made while it had a stale keyframe association, no leaf
geometry and no rotation. A negative from comparing two renders inherits every
defect of both. It sat refuted for weeks because the instrument that killed it
was the thing under repair.
**The evidence, in the order that matters:**
* **35 elements, three screens, 0 errors** — 16 bit-set/additive, 19
bit-clear/alpha-over, every label read out of the command stream.
* **No rival field.** Of every bit of the first twelve header words, **exactly
one** separates those 35 without error. That is the control `+0x08 = 0x8050`
failed, and without it a perfect partition on 35 samples means nothing.
* **`ptbtn00` `0x0110` alpha-over vs `ptbtn00f` `0x0112` additive** — same screen,
same bundle, adjacent draws, one bit apart. And `ptbtn01f`/`ptbtn11f` are
bit-clear and alpha-over, so it is **not** "focused variants are additive".
* **A prediction I committed before capturing it**, on `GP_OPTIONS` — a different
archive, never captured: *falsified if `po_menu_eff01/02/03` draw alpha-over or
anything else draws additive*. The game drew exactly those three additive and
nothing else.
⚠️ **Reach.** `.prm` primitives have no `T8aD` header, so the bit cannot speak for
them — `pteff00.prm`/`pteff02.prm` are *measured* alpha-over. Only two UI blend
states have ever been observed, so nothing here describes a third. And `src = ONE`
in both, so the alpha weighting is the shader's; this still says nothing about
whether texels are stored premultiplied.
### ⬅ Your three asks
**1. Is `pteff10` additive on the MAIN MENU too? — YES.** The 819.2 × 720 draw is
`pteff10` (409 × 144 at its resting 200 % × 500 %), additive, **in all three menu
sessions, every frame**. `pteff12` likewise. My coverage table listing `pteff10`
as uncovered on the menu is corrected. And the bit says so independently:
`pteff10` is `0x8832`.
**2. The sweeps' alpha as a function of position — it is on the DISC, four
keyframes.** [`data/sweep-leaf-ramp.txt`](../re/data/sweep-leaf-ramp.txt):
| leaf | loop | keyframes (t, x, alpha) | rot | scale y |
|---|---|---|---|---|
| `ptloop01` → `pteff03` | **600 u** | (0, −639, **255**) (150, −39, **128**) (540, 1521, **255**) (600, 1521, 255) | +30° | 600 % |
| `ptloop02` → `pteff03a` | **720 u** | (0, 1721, **0**) (150, 1111, **128**) (630, −839, **255**) (720, −839, 255) | −45° | 800 % |
✅ The GPU agrees on **sign every time** and on **magnitude within ~15 %** across
three sessions. And a second, independent identification agrees: the measured
alpha spans 45…242, and **only `pteff03a` declares alpha below 128** — the strip
seen at 45 is the 1303-tall one, which the AABB geometry says is `pteff03a` for a
completely different reason.
⚠️ It **cannot** separate the two declared slopes (25 % apart against a
quantisation of 6.4 px and one alpha level over 3–4 frames), and absolute phase
is unchecked — the AABB-left ↔ element-x mapping under rotation and pivot is not
established. Note your parked `x = 1521` **is** `pteff03`'s resting hold; the
game simply loops past it.
**3. Does `kind & 0x2` belong in your exporter? — Not mine to grant, and here is
what the decode supports.** It is 0 violations in 15 493 declaration entries over
24 UI paks, two-sided, so it holds anywhere `parse_build` parses. What it says is
*"the declaration marks this element focusable"* — **not** that the cursor can
reach it at run time; nothing here tests reachability. If your classifier only
needs "does this take focus", that is exactly what the bit is. Whether to change
a classification other code reads is your call, and your mission's, not mine.
## ✅ 2026-08-31 (final) — your standing ask, the title, and a coverage claim of mine that was wrong ## ✅ 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`. **`ptframe4`, `pteff21`, `pteff22`, `pteff23` are ADDITIVE.** So is `pteff10`.

8
docs/re/structures/ui-blend-mode-measured.md
View File

@@ -1,5 +1,13 @@
# The UI blend mode — ✅ **MEASURED**: the frames are drawn **ADDITIVE** # The UI blend mode — ✅ **MEASURED**: the frames are drawn **ADDITIVE**
> 🔴 **SUPERSEDED IN ITS CLASSIFICATION, 2026-08-31.** This page says the mode is
> **measured** and that *"which field selects the mode is still unknown"*. The
> field is now decoded — **`T8aD +0x04` bit `0x02`** —
> [`ui-blend-mode-decoded.md`](ui-blend-mode-decoded.md). Every measurement below
> stands and is the evidence that decode is fitted to; the instruction to read it
> as per-element facts because no rule exists does not.
**Status:** ✅ `CONFIRMED`, classification **measured** — nothing on the disc **Status:** ✅ `CONFIRMED`, classification **measured** — nothing on the disc
selects it, and this is what the running game tells the GPU, per draw, on two selects it, and this is what the running game tells the GPU, per draw, on two
screens. 2026-08-31. screens. 2026-08-31.