`main_menu` -- the milestone's gate -- agrees with the reference renderer to
within 3/255 on every channel of every pixel, RMSE 0.38 %, no pixel above 4 %.
Nine of the twelve screens are at or under that; two are byte-identical.
Three exceed it, and each gets a cause rather than a wider tolerance:
* `title` (max 6): every disagreement is INSIDE A TIE -- the derived order and
the CLI's measured-off-the-game order differ only among elements with
identical layer keys. That is exactly the residual HANDOFF Q3 documents and
the export already declares in `unresolved: paint_order_ties`. Cost: 904 px at
4-6/255 in one glow band. The port keeps the stable sort; fitting it to one
screen's capture would be tuning.
* `title_jp` (max 154): `ptlogo_eff2` at 125 % is the only drawn element in the
whole export at a scale that is not a whole multiple of 100 %, and `title_jp`
is the only screen over 6/255. Same fact twice. `ui_layout::blit` samples the
source at the destination pixel's top-left corner; a GPU samples at its
centre, and at 125 % those disagree on one column in five.
I think the CLI is the one that is wrong -- corner-sampled nearest is a
half-pixel bias toward the top-left that no rasteriser produces. But that is a
reading, not a measurement: it needs a framebuffer capture of the Japanese
title screen, so it is filed in BLOCKED.md as a question. The port is NOT
changing to match, because matching would mean reproducing a half-pixel offset
on purpose to make a number smaller.
* `extras` (max 4): two pixels.
Also reconciled: the pivot question predicted a P1 diff could not distinguish
the declared pivot from half the texture, because both renderers use the
declared one. That held. Recorded so the agreement is not later mistaken for
evidence -- and P2 will not settle it either.
BLOCKED.md's `/reborn` HEAD updated to bc6354d, with a note that the mount is
read-only by design and `git -C /reborn pull` fails rather than being skipped.
FORMAT is bumped to v2 with a "Changes from v1" table giving a reason per row.
v1 was written before HANDOFF answered Q1 and Q3 and before the two-colour
modulate was known; each change is a thing v1 could not have said. The paint
order moves from `unresolved` into the export, because Q3 decoded it — a u16
layer key at +0x0A, stable-sorted — and a decoded answer is read in the
exporter. `paint_order_ties` replaces it, because the tie-break is still
unknown.
Where a layer key is not in the file it comes from the decoders' table of keys
measured off the running game. That is a different kind of fact, so it is
labelled: `layer_source` is "sprite", "implied" or "none".
BLOCKED is reconciled against HANDOFF at /reborn e81dcad. Seven of its ten rows
are answered and are moved out; what remains is Q8 (no cue-to-event binding),
the two Q10 unknowns (which BGM, and where a loop restarts), Q9's unsettled
skippability, Q4's untested NEW GAME, and Q6's undecoded boot driver.
It also raises one question back, found by counting the export rather than by
reverse engineering anything: the decoders document a .t32 element's pivot as
"exactly half the decoded texture's dimensions (verified 7/7 on the tutorial
bundle)", and on GP_TITLE that holds for 55 of 93 sprite-bearing .t32 elements.
38 do not, some grossly — ptlogo_back2 is 1118x262 with pivot (500,117) where
half is (559,131). It changes nothing today, because the exporter emits the
declared pivot and the pivot only matters when scale != 100%. But scale IS
animated here — 177 keyframes across GP_TITLE are not 100%, including on the
title screen P1 has to draw — so the question of what the running game anchors a
scale to is worth an answer before P2. Noted there that the port and
`sylpheed-cli screen render` make the same choice, so a P1 diff cannot
distinguish them and their agreement is not evidence.
