Gate: `godot --path port -- --boot --film=/tmp/boot` runs publisher_logo ->
developer_logos (4.65 s) -> title (8.57 s), holding on the title after 13.05 s,
each screen fading in, holding, and fading through black into the next.
verify-screen now covers all 16 screens and passes `--all` to the reference
renderer: the exporter addresses by pak entry index, which is the numbering
`--all` uses, and without it `--build 10` would land on entry 12. The four new
splash bundles come in at max 1-2/255. The three known differences are unchanged.
Also recorded, taken from the RE agent rather than re-derived:
* Focus stays "replace" -- over-vs-instead is unobservable (the focused sprite
covers the base at 100 % of base-visible pixels; the two compositions differ by
RMSE 1.1, under the gamma floor). The port guessed right for the wrong reason.
The real gap is that ptbtn0Nf.rat declares TWO sprites -- a glowing ring, then
the label -- where ptbtn0N.rat declares one. P5's, and the ring's placement is
not decoded, so it will be authored from the capture and marked as such.
* RMSE against captures has a FLOOR: capture ~ 255*(render/255)^g, g ~ 1.49 menu
and EXTRAS, 1.34 title, and it is a ramp the GAME installed, not a capture-path
artefact to subtract. Narrow reach (fitted on mostly-dark patches), so the port
will not extrapolate it and will not apply it to rendered output. It is a
comparison constant, not a rendering one.
* Rotation is escalated to a human and the port has NOT acted. The RE half is
answered -- about the declared pivot, measured -- and it has zero effect on the
five screens at rest.
WHAT I WANTED FROM IT: 0ed33bc, "a RATC child's name is stated, not inferred".
A child was named by scanning backwards for the last printable run of bytes
before its magic. For `pteff05.t32` the three trailing payload bytes are
38 41 58 = `8AX`, which beat the real name, so the child registered under a name
no element declares and resolved to no sprite.
`pteff05.t32` is the full-resolution background of all five menu screens.
Every menu render this port has produced has been missing its background, and
P1 wrote that up as a fact about the disc -- "the bundle carries zero RATC
children for either, so there is no texture on the disc to export". That is
retracted in docs/DECISIONS.md rather than edited away.
The re-export is contained: six new sprites and nothing else. pteff05 on
main_menu/extras and their JP twins, pteff04 on both titles. Each gains a
`sprite` line and moves `layer_source` from "implied" to "sprite" -- the layer
key is now read from the file instead of the decoders' table of keys measured
off the running game, which is the ratchet turning the right way.
pteff05.png is 1280x720; ptbase.png, which had been carrying the background
alone, is 640x360 drawn at 200 %.
Measured against the live capture rather than the other renderer: settled
main_menu RMSE 8.05 % -> 5.92 %. The reference renderer was missing the same
element for the same reason, so no renderer-vs-renderer diff could have found
this -- the third time a capture has caught something both renderers agreed on.
Their question was which screens the other four of "six" elements are on. The
six span the whole 12-screen export: ptframe1/ptframe2 on main_menu and
main_menu_jp (trailing run alpha 0xff, VISIBLE -- their rule accepts these, and
they are the four it revealed disc-wide), and pteff02 on title and title_jp
(trailing run alpha 0x00, TRANSPARENT -- their rule excludes it).
That exclusion is correct, and their own measurement is what proves it: pteff02
is the 25 % dim quad, and they measured the title render going from +13.14 to
+0.55 against the plate-free capture once it is drawn. So `rest` must stay at
0x40 and must not move to the transparent trailing run -- which is what their
alpha rule does. Two investigations converging from opposite directions, and no
third discriminator is needed.
Also recorded: the reference renderer was stale for three diff runs and reported
success throughout, and the shape worth naming is that a build system reporting
success is not evidence the artifact you are about to trust is the code you
pinned. The RE agent hit the same class of trap this session from the other side.
BLOCKED.md: the loop/hold question is answered (groups hold -- ptloop01/ptloop02
park off-screen at x=1521 and x=-839), and the rest_plateau entry is closed as
fixed, noting the adopted rule is theirs and not the looser one this port
proposed.
agrees with the timeline
P2's gate is the buttons sliding in, and `tools/screen-strip` renders the strip
that shows it. But the useful result came out of checking where the animation
settles.
On 8 of 12 screens the settled timeline is BYTE-IDENTICAL to the declared `rest`
pose -- the port walks the keyframes with an authored time unit and arrives, to
the pixel, where the pinned decoders independently say the screen rests. On
`main_menu` the two differ in exactly one region, 400x470 at (440,108): the
bounding box of `ptframe1` and `ptframe2` and nothing else.
`rest` puts both at their first keyframe, off-position and transparent. The
capture of the running game shows them -- the bright circuit bracket around the
menu. Cropping the same region from the capture and from both renders puts the
ring and its elbow trace in the timeline render pixel-aligned with the game's,
and absent from the rest render. Geometry, so it does not depend on the
capture's gamma or on its having been taken with NEW GAME focused.
`ui_layout::rest_plateau` excludes a trailing run of identical keyframes because
it is normally the exit. On an element with NO exit animation the trailing run IS
the hold. The condition that identifies these exactly, with no false positives
here, is "the final untimed keyframe has the same pose as the last timed one" --
six elements, and `rest()` misses all six. Filed in BLOCKED.md for the RE agent:
the decoders are pinned and are not this port's to fix, and `sylpheed-cli screen
render` is missing the bracket too.
Worth saying plainly what this does to P1: the port and the reference agreed on
`main_menu` to 3/255 and BOTH were missing two elements the game draws. Two
renderers reading one field through one decoder agreeing is not evidence the
field is right. BLOCKED.md had already said that about the pivot; here it bit.
The title is NOT settled and P2 does not claim it. `rest` and the timeline
disagree there by 142-247/255, the only live title capture composites the PRESS A
plate over build 4 so it cannot be diffed against the title alone, and both of
the port's modes draw a cyan glow slab the game does not have -- a third problem,
P3's. Recorded as an open question rather than resolved by tuning.
Also reconciled against the RE agent's new work: Q8 is answered -- the SE waves
are located in `Static.slb` (move/confirm/back), which unblocks P6's audio; and
the title's transitions are a lookup by NAME, giving P3/P5 the game's own screen
vocabulary as candidate `goto` targets, marked as the name match it is.
`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 690683d, 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 d69272e. 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.
