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

131
authored/rendering.json
View File

@@ -136,116 +136,37 @@
"on the menu' would have contradicted the pixels for no reason."
],
"loop_leaf_kind": "measured",
"additive_elements": {
"main_menu": [
"pteff12",
"ptframe1",
"ptframe2",
"ptloop01",
"ptloop02"
],
"extras": [
"pteff10",
"pteff20",
"ptframe3",
"ptframe4",
"pteff21",
"pteff22",
"pteff23",
"ptloop01",
"ptloop02"
],
"press_start": [
"ptbtn00f"
],
"title": []
},
"additive_elements_why": [
"TRANSCRIBED, not authored, and the distinction is the whole entry. The port",
"composited every element with straight alpha-over and four came out too dark",
"against the capture. I measured from my side that the shortfall scales with",
"the BACKGROUND, and that of alpha-over / additive / screen, additive roughly",
"halves the error (DECISIONS.md, two-background composite solve, control 0.0000).",
"That was a PROPOSAL and stayed one: nothing on the disc selects a blend mode",
"(`docs/re/structures/t32-blend-mode-not-on-disc.md`), so choosing one was not",
"mine to do.",
"additive_elements_deleted_why": [
"✅ DELETED 2026-09-01, and the deletion is the point.",
"",
"It is now MEASURED OFF THE RUNNING GAME. The Decoder logged RB_BLENDCONTROL0",
"per draw in Canary and drove the game to both screens:",
"`docs/re/structures/ui-blend-mode-measured.md`, table in",
"`docs/re/data/ui-blend-mode-measured.txt`. 0x01010101 is src=ONE dst=ONE,",
"additive. Elements are identified by the PIXEL SIZE of their quad against",
"sprite dimensions.",
"This held `additive_elements`, a per-screen list of element ids transcribed",
"from the Decoder's per-draw RB_BLENDCONTROL0 log. PORT-MISSION section 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.'",
"",
"✅ Their control, and it is what makes this a blend result rather than a shader",
"result: ONE pixel shader, 0xE59B2B3DA4AA9008, runs with BOTH states on the main",
"menu -- 12 draws additive and 18 alpha-over. The frames and `ptbase` share a",
"shader. Only the blend register differs.",
"The blend is now DECODED -- `T8aD +0x04` bit 0x02, docs/re/structures/",
"ui-blend-mode-decoded.md -- and reachable since formats-pin-2026-09-01 exposed",
"`ui_layout::sprite_blend_additive` and `blend_additive_by_name`. The exporter",
"emits `blend_additive` per element and per nested focus/leaf element, and",
"ScreenView reads it there.",
"",
"`ptloop01` and `ptloop02` are the two ROTATED SWEEP STRIPS, added 2026-08-31.",
"`docs/re/structures/ui-blend-mode-measured.md`'s summary table names them",
"additive in the same row as the frames, and their control 1 identifies them: the",
"NDC->pixel conversion reproduces 1134 and 1303 px, two heights measured by a",
"different tool in a different session (`data/title-sweep-drawn-at-rest.txt`), on",
"BOTH screens. So this is an identification with an independent check behind it,",
"not a name match -- the automatic matcher reports 'no match' for these two.",
"🔴 CHECKED BEFORE THE SWAP, and the map turned out to be a SUBSET rather than",
"the answer. Over main_menu, extras, press_start and title:",
"",
"⚠️ AND IT CHANGES NOTHING VISIBLE TODAY, which is why it is worth writing down.",
"On the menus the port runs the leaf group ONCE and parks it off-screen, so these",
"two paint no pixels at any pose the port can be put in (checked: suppressing",
"both sprites at leaf-time 100, 200 and 300 changes 0 pixels). The entry is here",
"because it is measured, not because it does anything. What it DOES do is fix the",
"instrument for the menu-looping question -- see `loop_leaf_on_screens_why`.",
" 15 the map called additive AND the disc agrees",
" 0 the map called additive and the disc does not <- no contradictions",
" 17 the disc calls additive and the map did not",
"",
"⚠️ EVERY ID HERE IS A MEASURED DRAW, and the list stops where the measurement",
"does. THREE THINGS ARE NOT IN IT:",
"So nothing transcribed was wrong; it was incomplete, and was being read as",
"complete. The 17 include `pteff03`/`pteff03a` -- the sweep LEAVES, which are",
"what `draw_leaf_for` actually puts on screen while the map listed their parents",
"`ptloop01`/`ptloop02` -- and TWELVE on `title`, where this map was deliberately",
"empty and the port therefore drew every title effect alpha-over.",
"",
" `ptframe4` -- NOT MEASURED. It never appears in either capture's draw list,",
" and the port measures it at 10.46x the frame mean, dark, exactly like its",
" three siblings. It is the most tempting entry on this page and it is not",
" going in: 'the other three frames are additive' is a RULE, and the Decoder's",
" own warning with the table was to take it as per-element facts because which",
" field selects the mode is still unknown. A fourth frame added on the strength",
" of a pattern would be indistinguishable from a measured one in a month.",
"",
" The two unidentified additive draws per screen (889.6x1134.0 and",
" 1299.2x1303.2) -- these are the rotated sweep strips, whose height the",
" Decoder's OWN control reproduces independently. Additive, but the port draws",
" them through `draw_leaf_for` and I have not checked that path.",
"",
" The 819.2x720.0 additive draw, which matches no sprite on either screen.",
"",
"⚠️ AND NOT PREMULTIPLIED TEXTURES. The measured non-additive state is",
"0x07010701 -- src=ONE, which is the PREMULTIPLIED form of alpha-over. It would",
"be easy to read 'so the textures are premultiplied and the port's straight",
"alpha-over is wrong everywhere'. The Decoder flagged this before I could: src",
"being ONE means the fixed-function stage multiplies the SHADER's output by 1,",
"and the shader has not been read. The port's alpha-over path measures 0.92-1.31x",
"the frame mean on `ptbase`/`pteff05`, so it is not visibly wrong. Nothing here",
"changes it.",
"",
"🔴 2026-09-01 — THE JP SCREENS ARE NOT IN THIS MAP, AND THAT IS AN UNMEASURED",
"CLAIM THIS FILE IS MAKING BY OMISSION. Declared here rather than left silent.",
"",
"`main_menu_jp` contains exactly the elements `main_menu` marks additive --",
"ptloop01, ptloop02, ptframe1, ptframe2, pteff10, pteff12 -- and `extras_jp`",
"contains all nine of `extras`'. This map is keyed by SCREEN NAME, and the",
"Decoder's RB_BLENDCONTROL0 log was taken by driving the game to the ENGLISH",
"screens. So the port draws these elements additive on the EN screens and",
"alpha-over on the JP ones, and nothing measured says the game does that.",
"",
"The port is therefore asserting, by omission, that the JP build blends the same",
"elements differently from the EN build -- which is the LESS likely of the two",
"possibilities. Extending the map would extrapolate a measurement onto a build",
"nobody drove to, which is not the port's to do. Both options assert something",
"unmeasured; only one of them is visible. This paragraph is how the quieter one",
"is made visible. Asked in docs/port/BLOCKED.md.",
"",
"⚠️ It does not affect the deliverable: PORT-MISSION §7 puts localisation beyond",
"English out of scope and the JP screens are not in the boot path. It affects",
"`tools/port/verify-screen`, where main_menu_jp and extras_jp DIFFER by 0.79 and",
"0.66 -- magnitudes that sit with `title`'s 0.44 sweep-phase residual rather than",
"with their own EN twins' 3.94 and 6.74, which is consistent with the JP rows",
"carrying no additive contribution at all. Consistent with, not established."
"A name-keyed map can only answer for a screen somebody drove the game to. That",
"is what made the Japanese menus an open question (BLOCKED.md H6): the port drew",
"main_menu additive and main_menu_jp alpha-over, asserting by omission that the",
"JP build blends differently. The bit is on the disc for every screen at once, so",
"that asymmetry is now answered statically and H6 needs no capture."
]
}