8d2c092788
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.
4.4 KiB
Waiting on the RE agent
What this port cannot do until an answer lands in
/reborn/docs/port/HANDOFF.md.
Recorded so it is not re-discovered every iteration.
None of these may be guessed. A value invented here is indistinguishable from
a decoded one a month from now. Where a milestone can proceed with a placeholder,
the placeholder goes in authored/ with a why naming the question it stands in
for, so it is deleted rather than forgotten when the answer arrives.
Last reconciled against HANDOFF.md on 2026-08-28, at /reborn HEAD e81dcad.
Still open — these block work
| Milestone | Needs | HANDOFF | State |
|---|---|---|---|
| P6 audio | which cue fires on move / confirm / back | Q8 | ❔ open. The cue table is complete; the event binding is not. P6 cannot bind a sound to a keypress without inventing it. |
| P6 audio | which BGM the menu plays | Q10 | ❔ not on the disc. All 32 banks are named BGM_001…BGM_109 with no semantic name anywhere. The port is choosing a track, and that choice is authored. |
| P6 looping | where a menu loop restarts | Q10 | ❔ BGM_001 fades out at 167.663 s into 6.15 s of silence, and no loop-point field has been identified. A menu loop is authored. |
| P4/P7 video | whether Ⓐ skips a movie | Q9 | 🟡 unsettled — the corpus says Ⓐ skips every time, the boot harness never taps during a movie because it breaks the title. P4 can play the movie; it cannot yet say what a button press does during one. |
P5 NEW GAME |
what Ⓐ on NEW GAME opens |
Q4 | ❔ untested: Ⓐ on it hangs the emulator. The other four destinations are measured. |
| P3 sequencing | what code decides to advance the boot sequence | Q6 | 🟡 the order is observed and the attract cycle timed (~8–10 s idle → fade → ADV.wmv in full → title). The driver is not decoded. P3 can reproduce the observed behaviour and must say it is reproducing an observation. |
Answered since this file was last written — no longer blocking
Q1 (keyframe time unit — linear ramp, 2 units per rendered frame, 1 unit = 1/60 s
measured), Q2 (which build is which screen), Q3 (paint order — a u16 layer key
at +0x0A, decoded), Q5 (navigation: ⬆⬇ wrap, ⬅➡ nothing, Ⓑ up with focus
restored), Q7 (transitions: a fade through black, fade-in decoded, ~0.4 s fade-out
measured), Q9 (ADVERTISE_MOVIE → ADV.wmv is boot intro and attract; MS00A →
S00A.wmv is the new-game intro), Q10 (a bank is two stems played together —
do not concatenate), S1 (Ready Room: no-go).
Three of those are measured, not decoded, and so are authored here rather than exported:
| Authored because it is not on the disc | HANDOFF | Where it lives |
|---|---|---|
1 keyframe unit = 1/60 s |
Q1 | not yet written — P2 |
| initial menu focus (not stable across boots; pick one and say so) | Q5 | not yet written — P5 |
| the ~0.4 s fade-out and the 0.17–0.23 s black hold | Q7 | not yet written — P3 |
Questions this port has raised
Not blocking anything today; raised because the port found them and a guess here would be believed later.
The pivot is not half the texture on GP_TITLE
sylpheed-formats's ui_layout::Element::pivot_x is documented as "for a .t32
element this is exactly half the decoded texture's dimensions (verified 7/7 on
the tutorial bundle)". Counting it over the whole of GP_TITLE as exported:
- 55 of 93 sprite-bearing
.t32elements match within ±1 px. - 38 do not, and several are not close:
ptlogo_back2is 1118×262 with pivot (500, 117) where half is (559, 131);ptmsgis 223×38 with pivot (123, 19) where half is (111.5, 19) — the Y matches and the X does not.
This changes nothing today: the exporter emits the declared pivot and never
derives one, and the pivot only affects drawing when scale ≠ 100 %. But it does
matter, because scale is genuinely animated here — 177 keyframes across
GP_TITLE are not 100 %, including on the title screen the port must draw at P1.
The question for the RE agent, when it is cheap to answer: does the running
game anchor a scale to the declared pivot, or to half the texture? The two
differ by up to 59 px on ptlogo_back2, which is visible. Until then the port
follows the decoders and uses the declared pivot, which is also what
sylpheed-cli screen render does — so a P1 diff cannot distinguish them, and
agreement between the two is not evidence.