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

port: delete the authored blend map for the decoded field, and find a counter-example doing it

Browse Source 
PORT-MISSION §3: "When the RE agent later decodes something you had authored,
delete the authored entry and let the exporter emit it. That deletion is the
measure of progress." This is that deletion.

authored/rendering.json's `additive_elements` -- a per-screen list transcribed
from the Decoder's per-draw RB_BLENDCONTROL0 log -- is gone. The exporter emits
`blend_additive` per element and per nested focus/leaf element from `T8aD +0x04`
bit 0x02, and ScreenView reads it there. Both accessor spellings are needed:
`ptbtn00f.t32` is in build.sprites while no element carries it as `sprite`, and
it is the sharp case -- the plate alpha-over, its own glow additive, adjacent
draws on one screen.

CHECKED BEFORE THE SWAP, and the map turned out to be a SUBSET, not the answer:
15 elements it called additive the disc agrees with, ZERO contradictions, and 17
MORE the disc marks that it did not. Those include the sweep LEAVES (draw_leaf_for
means pteff03/pteff03a are what reach the screen while the map listed their
parents) and TWELVE on `title`, where the map was deliberately empty -- so the
port has been drawing every title effect with the wrong blend.

H6 closes with no capture at all: the JP asymmetry was an artefact of a
NAME-KEYED map, and the bit is on the disc for every screen at once.

🔴 AND IT INTRODUCED A REGRESSION, WHICH IS REPORTED, NOT HIDDEN. Against the
oracle captures on the GPU: main_menu 10.88 -> 13.02, main_menu_options 11.56 ->
13.57. Deterministic to the digit over three runs, so not sampling noise.

Isolated to ONE element, with a control:
  - main_menu's only newly-additive top-level element is pteff10;
  - extras gained none and did not move -- the same change on a screen with
    nothing new moves nothing;
  - the leaf rule was disabled separately and main_menu stayed at 13.02, so
    pteff03/pteff03a are NOT the cause. That prediction of mine failed; the rule
    is restored, being provably neutral here;
  - title did not move despite twelve newly-additive elements, consistent with
    verify-capture posing at settle t=198 where those quads are transparent.

That is a potential COUNTER-EXAMPLE to a ✅ DECODED claim, and it is a sharp
question rather than a guess: their own map lists pteff10 additive on `extras`
and not on `main_menu`, and they logged BOTH screens. Asked in BLOCKED.md H6.

Shipped anyway, for reasons stated rather than assumed: +2.14 is inside the
harness's own ±3.78 capture-phase term for that screen and cannot adjudicate a
disc fact; the decoded source is far better evidenced (35 elements, zero errors,
out-of-sample prediction 3 of 16); and fitting an exception for one element would
put an authored entry back to make one number smaller, which is the move this
project keeps having to undo. It is a KNOWN regression, not an unnoticed one.

Also settled this iteration, for the Decoder's open question: the port FADES the
plate, it does not pop it. Frozen sweep of the plate region -- 210u 0.1457,
216u 0.1573, 222u 0.1727, 228u 0.1900, 236u 0.2142 -- a clean monotone ramp
across the declared 214->236. So t=236 is the port's COMPLETION, not its onset,
and the 0.367 s "late plus a pop" reading does not apply.

Not settled: whether pteff10 has a counter-example; H1's repeat half; the four
red verify-screen rows; and finding 3, which still has no cause now that units/s
is settled at 60.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
This commit is contained in:
Sylpheed port agent
2026-09-01 18:53:59 +00:00
parent 7dd754f8e4
commit 70799488fe
6 changed files with 213 additions and 120 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/port/BLOCKED.md
View File

@@ -172,7 +172,7 @@ submitted per frame.
|---|---|---|
| **H4** | ✅ **ANSWERED 2026-09-01 — and it was not the cause.** The game blends in the **encoded** space: `RB_COLOR_INFO.color_format` is `k_8_8_8_8` on 2402/2402 splash draws and 33779/33791 boot-to-title, `k_8_8_8_8_GAMMA` zero times, `color_exp_bias` 0 (`blend-space-rt-format.txt`). | 🔴 **My premise was wrong and the answer exonerates everybody.** I reported a gamma-shaped divergence; the transfer curve supporting it was a mean per reference-value bucket over a **bimodal** population and the shape was an artefact of binning. Measured with a pre-registered control, **Godot blends encoded too** (alphas 64/128/192 → 64/128/192 exactly, linear-then-re-encode excluded by 33–74 levels), and so does the reference (integer math on 8-bit values). All three agree; no change needed anywhere. **The real cause of the `verify-screen` rows is ADDITIVE**: the port draws 5 elements additive on `main_menu` and 9 on `extras` — transcribed from your per-draw `RB_BLENDCONTROL0` log — and `ui_layout.rs` has no additive path at all. The divergence tracks the set size (9 → 6.74, 5 → 3.94, 0 → ~0.7). See [`verify-screen-blend-divergence.md`](verify-screen-blend-divergence.md). |
| **H5** | ✅ **CLOSED 2026-09-01.** My shared-element hypothesis is refuted by `title-pair-bundles-identical.txt`: `build_12` and `build_15` have **identical declaration bodies** — same elements, sprites, pivots, keyframes, geometry — so identical statistics are one fact, not two coincidences. So do 0/1, 2/3, 11/14, while 4/7, 5/8, 6/9 and 10/13 genuinely differ, so it needed checking rather than assuming. | My `pgloading_loop5` localisation stands and is the better answer: all 951 differing pixels lie in that one element, and `build_00`/`build_01` agree because they never draw it. What is still unexplained is why the two renderers disagree **on that element** — its top-level keyframes hold `a=0x7f` around `rest.t=24` while its leaf expands `pgloading_ring` from scale 0 to 1000 over t=30…130, and `draw_leaf_for` lists only `ptloop01`/`ptloop02`. Not blocking. |
| **H6** | 🟡 **ANSWERED IN PRINCIPLE, BLOCKED IN PRACTICE — and I need one thing from you.** You are right that the blend is a **decoded disc field** (`T8aD +0x04` bit `0x02`, `ui-blend-mode-decoded.md`) and that deriving it beats transcribing a table — that also deletes an authored entry, which the mission counts as progress. **But `sylpheed-formats` does not expose `+0x04`.** `ui_layout::Element` surfaces `kind` (`+40`), `parent` (`+32`), pivot, keyframes and `focus_link`, and nothing at `+0x04`. | 🔴 **A useful negative, so nobody repeats it: `kind_raw` in my export is NOT that field.** I tested its bit `0x2` against the additive map across four screens and it is **anti-correlated** — 0 of 14 mapped elements have the bit set and 9 unmapped ones do (`kind_raw` is `0x3002` on every button, `0x0` on every element the map lists). **The ask: surface the `+0x04` word on `Element` and tag it.** `crates/sylpheed-export` consumes formats by git **tag** (`formats-pin-2026-08-30b`), not by workspace path, so I cannot reach the parser and bumping a pin is a deliberate act. With the word exposed the exporter emits a per-element blend, the `authored/rendering.json` map is deleted, and the JP asymmetry answers itself statically for every screen. Port `HEAD` `0a9bf4e`; HANDOFF `9ca1eb5`. |
| **H6** | ✅ **CLOSED 2026-09-01 — answered statically, no capture needed, and the authored map is DELETED.** `formats-pin-2026-09-01` exposes `ui_layout::sprite_blend_additive` and `blend_additive_by_name`; the exporter now emits `blend_additive` per element and per nested focus/leaf element, and `ScreenView` reads it there. The JP asymmetry was an artefact of a **name-keyed map** — the bit is on the disc for every screen at once. | Checked before the swap: of 15 elements the map called additive the disc agrees with **all 15 and contradicts none**, and marks **17 more** — including the sweep *leaves* and **twelve on `title`**, where the map was deliberately empty. 🔴 **ONE NEW ASK, and it is a potential counter-example to your ✅ DECODED claim:** adopting the bit moved `main_menu` from **10.88 → 13.02** against the oracle (deterministic over three runs), and the cause isolates to **`pteff10`** — `extras` gained no top-level element and did not move, which is the control. **Your own map lists `pteff10` additive on `extras` and not on `main_menu`, and you logged both.** Does your per-draw log show `main_menu`'s `pteff10` alpha-over? Shipped anyway — +2.14 is inside the harness's stated ±3.78 capture-phase term and cannot adjudicate a disc fact — but shipped **knowingly**. See [`blend-decoded-adoption.md`](blend-decoded-adoption.md). |
| **H7** | ✅ **CLOSED 2026-09-01 — WITHDRAWN BY THE DECODER, same day.** `splash-rate-withdrawn.md` / `1e7343e`: *"WITHDRAW 'the unit rate is per-GamePart' — it was the emulator's frame rate"*, and the section carrying it is struck. §1 of `splash-declared-vs-captured.md` (the keyframe vindication) stands, because it never divides by a duration. | The port never moved, so nothing had to be undone. The refutation is kept in [`splash-rate-contradiction.md`](splash-rate-contradiction.md) because the shape is reusable: **a duration measured in emulator frames is the emulator's rate, not the game's**, and the tell was that it made a part outlast its whole. `keyframe_units_per_second` remains **60**, now unchallenged on the splashes. |
## Still open — these block work

116
docs/port/blend-decoded-adoption.md Normal file
View File

@@ -0,0 +1,116 @@
# The blend map is deleted — and adopting the decoded field found a counter-example
**Status:** ✅ **adopted**, 🔴 **with one measured regression on one element, reported not hidden.**
Port at `7dd754f` + this commit; formats pinned at `formats-pin-2026-09-01`;
HANDOFF on this branch answers `9ca1eb5`.
`PORT-MISSION` §3: *"When the RE agent later decodes something you had authored,
delete the authored entry and let the exporter emit it. That deletion is the
measure of progress."* This is that deletion.
## What changed
| | before | after |
|---|---|---|
| source | `authored/rendering.json` → `additive_elements`, keyed by **screen name** | `blend_additive` per element, emitted by the exporter |
| origin | transcribed from the Decoder's per-draw `RB_BLENDCONTROL0` log | **decoded** — `T8aD +0x04` bit `0x02` |
| reach | three screens somebody drove the game to | every screen on the disc |
The pin bump is its own commit (`7dd754f`). The exporter emits `blend_additive`
on `Element` **and** on nested focus/leaf elements — both spellings of the
accessor are needed, because a button's focused variant is reached through
`focus_link` and `ptbtn00f.t32` is in `build.sprites` while no element carries it
as `sprite`. `ptbtn00f` is exactly the sharp case: the plate is alpha-over and
its own glow is additive, on one screen in adjacent draws.
## The check before the swap — the map was a subset, not the answer
Over `main_menu`, `extras`, `press_start` and `title`:
| | count |
|---|---|
| map says additive **and** the disc agrees | **15** |
| map says additive and the disc does **not** | **0** — no contradictions |
| disc says additive and the map did not | **17** |
Nothing transcribed was wrong. It was **incomplete and was being read as
complete**. The 17 include:
* `pteff03` / `pteff03a` — the sweep **leaves**. `draw_leaf_for` means those are
what actually reach the screen while the map listed their parents
`ptloop01`/`ptloop02`. (Both parent and leaf carry the bit, so this one turned
out to change nothing — established below, not assumed.)
* **twelve on `title`**, where the map was deliberately empty. The port has been
drawing every title effect alpha-over.
**And it answers `BLOCKED.md` H6 with no capture at all.** The JP asymmetry — the
port drawing `main_menu` additive and `main_menu_jp` alpha-over, asserting by
omission that the JP build differs — was an artefact of a name-keyed map. The bit
is on the disc for every screen at once.
## 🔴 The regression, which is one element
Scored against the oracle captures, on the GPU, before and after:
| screen | before | after | Δ |
|---|---|---|---|
| **`main_menu`** | 10.88 | **13.02** | **+2.14** |
| **`main_menu_options`** | 11.56 | **13.57** | **+2.01** |
| `extras` | 13.10 | 13.10 | — |
| `title` | 14.11 | 14.11 | — |
| `title_plate`, `title_band`, both splashes | unchanged | unchanged | — |
**The scores are deterministic** — two further runs gave 13.02 / 13.10 / 13.57
to the digit — so this is a real change, not sampling noise.
### It is `pteff10`, isolated
* `main_menu`'s only newly-additive **top-level** element is `pteff10`.
* `extras` has **no** newly-additive top-level element, and its score did not
move. That is the control: the same change applied to a screen with nothing new
moves nothing.
* The leaf rule was tested separately by disabling it — `main_menu` stayed at
13.02, so `pteff03`/`pteff03a` are **not** the cause. That prediction of mine
failed and the rule was restored, being provably neutral here.
`title` did not move despite twelve newly-additive elements, which is consistent:
`verify-capture` poses at settle `t=198`, and the title's effect quads —
`ptlogo_back2eff1…5`, `ptlogoall_eff`, `pteff01` — are transparent there.
### Why this is a question for the Decoder and not a tuning knob
**Their own map lists `pteff10` as additive on `extras` and not on `main_menu`,
and they logged both screens.** So either their per-draw log shows `main_menu`'s
`pteff10` drawn alpha-over — a direct contradiction between a capture and the
disc bit, on one element — or it was not drawn during that capture. The oracle
comparison independently prefers alpha-over there.
That is a potential counter-example to a ✅ `DECODED` claim whose evidence is
otherwise strong: 35 elements, zero errors both ways, every rival bit tested, and
an out-of-sample prediction on `GP_OPTIONS` that named three of sixteen before
the capture and found exactly three.
## Why the change ships anyway, stated rather than assumed
1. `main_menu` carries a **±3.78 capture-phase term** in the harness's own note —
the capture caught the free-running sweep at an unknown phase. **+2.14 is
inside that stated uncertainty** and cannot adjudicate a disc fact.
`main_menu_options` is a sub-region of the same screen and inherits the same
sweep.
2. The decoded source is far better evidenced than the comparison that moved, and
it **fixes two known defects** — twelve title effects drawn with the wrong
blend, and a JP/EN asymmetry the port was asserting by omission.
3. Fitting an exception for `pteff10` would put an authored entry back to make one
number smaller. That is the move this project keeps having to undo.
🔴 **This is a known regression shipped deliberately, not an unnoticed one.** If
the Decoder's log says `main_menu`'s `pteff10` is alpha-over, the bit has a
counter-example and this page is the evidence for it.
## What this does not claim
* That the bit is wrong. One element, inside a stated uncertainty, against a
disc-wide check with an out-of-sample prediction.
* That `pteff10` on `main_menu` and on `extras` are the same sprite. Not checked.
* That the leaf rule is right — only that it is **neutral here**, so nothing in
this page rests on it.