Files
Sylpheed/authored/rendering.json
Sylpheed port agent c453d8dade port: draw the measured additive blend -- main_menu 13.21 -> 10.67
The Decoder logged RB_BLENDCONTROL0 per draw in Canary on both screens.
0x01010101 is src=ONE dst=ONE, additive. That makes the blend a transcription
rather than my proposal, and they withdrew the "any blend you choose is authored"
instruction explicitly.

Their control is what licenses the change: one pixel shader, 0xE59B2B3DA4AA9008,
runs with BOTH blend states on the main menu -- 12 additive draws and 18
alpha-over. The frames and ptbase share a shader; only the blend register differs.

authored/rendering.json gains additive_elements per screen. Every id is a measured
draw and the reach is written beside it.

verify-capture: main_menu 13.21 -> 10.67 (0.06 % -> 0.02 %), extras 13.38 ->
11.43, main menu with ptbtn04 focused 13.82 -> 11.36. Per element, ptframe1
22.72 -> 4.17 and ptframe2 13.09 -> 3.32.

Neutrality control, free with the table: publisher_logo 2.17 and developer_logos
3.05 are unchanged to the digit. Those are the screens whose metric is absolute
and they carry no additive element, so the rewrite that routed every draw through
RenderingServer canvas items did not change the picture. The improvement is the
blend, not the plumbing.

RenderingServer rather than child Node2Ds because boot.gd calls view.queue_redraw()
from nine places and none reaches a child node -- bands would paint the previous
pose, which under --script=wait is a plausible wrong capture rather than an error.
Runs are recomputed per frame: the additive elements are consecutive on both
measured screens, and that is an accident of those two screens.

And the change first ran with the material left at its default MIX, moving
ptframe1 from 22.72 to 22.69. Nothing errored and a 0.03 move is a plausible
negative result. It was caught only because the measurement predicted a large move.

Not done: ptframe4 is now the worst element on EXTRAS at 16.19x the frame mean and
additive would plainly help it. It is not in the measured table, so it is not in
the file. Filed in BLOCKED.md with pteff21/22/23, which are also in no captured
draw.

Refuted, mine: "neither frame has a fully-opaque pixel" was true and was not the
discriminator -- pteff10 has max alpha 130, no opaque pixel, and measures nearly
exact. The direction survived; the reason for it did not.
2026-08-31 06:18:11 +00:00

167 lines
8.8 KiB
JSON

{
"format": "sylpheed.rendering/1",
"_": [
"WHICH decoded rules the runtime applies where. AUTHORED because it is a",
"choice about the REACH of somebody else's decode, not about the disc.",
"Delete an entry the day the decode covers the case outright.",
"",
"The exporter flags `leaf_carries_geometry` on 15 elements -- those whose",
"nested `.rat` leaf declares a scale or rotation the parent does not. That",
"flag is a CENSUS FACT and it is emitted for all 15. What is DECODED is",
"narrower: the Decoder fitted the game's own composed alpha (per-draw vertex",
"colours C3FFFFFF / B6FFFFFF = 195 and 182) against the ptloop leaves and got",
"one consistent time, then PREDICTED the quad centres to ~11 px. That covers",
"`ptloop01` and `ptloop02` and nothing else."
],
"draw_leaf_for": [
"ptloop01",
"ptloop02"
],
"draw_leaf_why": [
"The two the decode covers. `docs/re/structures/ui-leaf-vs-parent-alpha.md`.",
"",
"NOT DRAWN, though the exporter flags them and ships their data:",
"",
" `title_jp/ptlogo_eff2` -- OUT OF SCOPE, which is a better reason than",
" the caution this entry first gave. MISSION section 7 scopes out",
" 'localisation beyond English', and this element exists only on the",
" Japanese title. So it is not a thing the menu port has to answer, and the",
" parked Japanese-locale capture does not need reviving on its account --",
" that is the human's call and not something either agent widens quietly.",
"",
" It is ALSO undecidable here even if it were in scope. Its 125% is a POP,",
" not a steady scale: scale-0 -> 125% -> scale-0 between t=50 and t=107,",
" about 0.95 s. The leaf draws at 100%, as two superimposed copies at alpha",
" 160 and 80, each rotating 360 degrees over 960 units -- 16 s a turn. If",
" parent scale gates the leaf it is a 0.95 s flash; if the leaf runs free it",
" spins for 16 s. Nothing on the disc chooses and title_jp has no oracle",
" capture.",
" `build_12,15/pgloading_loop5` -- STILL NOT DRAWN, but the reason given here",
" was WRONG and is replaced. It read \"leaf scale (0,0). A zero scale is one of",
" the three historical failures this corpus names\" -- which describes t=0 and",
" t=30 and nothing after them.",
"",
" What the leaf actually holds, read out of the export: ONE element,",
" `pgloading_ring`, with a sprite, whose scale ramps 0 -> 250 -> 800 -> 1000",
" while its alpha rises to full at t=55 and falls to nothing by t=130. An",
" expanding, fading ring -- a loading pulse, not a degenerate record.",
"",
" 🔴 And it is VISIBLE at the instant this port poses. `build_12`'s settle",
" window is [40, 48], so the pose lands near t=44, where the ring interpolates",
" to scale 140 at alpha 143. So withholding it is not declining to draw",
" nothing; it is declining to draw something, and the old reason hid that.",
"",
" It stays withheld on the reason below, which is the one that always applied:",
" there is no way to adjudicate it here. The loading screens have no oracle",
" capture -- the RE agent records them as not reachable from the title path --",
" and `verify-screen` compares against a renderer that draws no leaves at all.",
" Drawing it would put unadjudicable content on a screen, which is the same",
" test `ptlogo_eff2` fails.",
"",
"AND THERE IS NO WAY TO ADJUDICATE EITHER HERE. `title_jp` has no oracle",
"capture, and `verify-screen` compares against `sylpheed-cli`, which does not",
"draw leaves at all -- so ANY leaf drawing increases that divergence whether",
"it is right or wrong. Its max went 155 -> 232 when they were drawn, and that",
"number is not evidence in either direction.",
"",
"What deletes this list: a decode covering those cases, or an oracle capture",
"of title_jp."
],
"draw_leaf_kind": "decoded",
"loop_leaf_on_screens": [
"title"
],
"loop_leaf_why": [
"WHICH screens replay a leaf's group instead of letting it run once and park.",
"MEASURED on the title, UNRESOLVED on the menus, so it is scoped to the title.",
"",
"The disc gives one pass: ptloop01's leaf runs t=0..600 and ptloop02's t=0..720,",
"each ending parked off-screen at x=1521 / -839. The port ran them once.",
"",
"THE ORACLE SAYS THEY LOOP ON THE TITLE. Across two title dwells the sweep quad",
"oscillates over its whole x range and resets hard to the same start value --",
"one reset inside the first dwell, two inside the second. A run-once-and-park",
"shows one traverse and then a constant x.",
"",
"🔴 THE LOOP-LENGTH FIELD CANNOT SETTLE THIS, and I had hoped it would.",
"`ptloop01` declares 600 with keyframes to exactly 600; `ptloop02` declares 720",
"to 720. SLACK ZERO -- and 'loops at 600' and 'runs once for 600 and stops'",
"write the identical header. 92.3% of records on the disc are in that state, so",
"the field discriminates loop length only where there IS slack, as the plate's",
"105-in-120 had.",
"",
"⚠️ THE MENUS ARE NOT COVERED, on purpose. Both declare the same 600/720, so",
"nothing on the disc distinguishes them -- but the oracle measurement is of the",
"title, and my own weak evidence points the other way for the menu: sweeping the",
"phase against live-main-menu.png, the port matches best with the sweeps",
"OFF-SCREEN (0.061%) and three times worse mid-screen (0.183%). If they looped",
"with a 600-unit period the sweep is on screen for roughly 73% of the cycle, so",
"a capture showing none is not nothing -- but it is one capture, and 'best",
"match' is a weak instrument for an absence. Two weak signals in opposite",
"directions is a reason to scope, not to pick.",
"",
"What settles the menu: a direct capture of it, which the Decoder has offered."
],
"loop_leaf_kind": "measured",
"additive_elements": {
"main_menu": [
"pteff12",
"ptframe1",
"ptframe2"
],
"extras": [
"pteff20",
"ptframe3"
]
},
"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.",
"",
"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.",
"",
"✅ 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.",
"",
"⚠️ EVERY ID HERE IS A MEASURED DRAW, and the list stops where the measurement",
"does. THREE THINGS ARE NOT IN IT:",
"",
" `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."
]
}