8e58077962
BGM_001.slb is three sub-waves (10 KB, 4.47 MB, 4.67 MB) and the decoder concatenates them into one 347 s track. That is a default nobody chose, not a decision: two near-equal halves could be intro + loop, two variations, or two halves of one piece, and a menu that loops its music needs to know which. Found while wiring the Audio Library up to the shared banks. Recorded in HANDOFF.md as a trap too, so the port does not build looping on top of the concatenated track before the question is answered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
133 lines
7.7 KiB
Markdown
133 lines
7.7 KiB
Markdown
# Primary objective — answer everything the menu port needs
|
||
|
||
**Status:** active, set 2026-08-28. This replaces "work the RE backlog" as the
|
||
agent's primary objective. It does not change what the agent *does* — it is still
|
||
reverse engineering — it changes what earns attention: an item is worth doing
|
||
when the menu port is blocked on it.
|
||
|
||
## Who builds what
|
||
|
||
**You do not build the port.** A separate agent will build it, from what you
|
||
produce. Your deliverable is decoded, verified, written-down answers plus the
|
||
reference data that proves them.
|
||
|
||
| | container agent (you) | port agent |
|
||
|---|---|---|
|
||
| decodes the disc | ✅ | ❌ — consumes your answers |
|
||
| measures the running game | ✅ | ❌ — no emulator |
|
||
| writes `docs/re/` and `docs/port/HANDOFF.md` | ✅ | reads them |
|
||
| Godot project, asset pipeline, transcoding | ❌ | ✅ |
|
||
|
||
If you find yourself designing an export schema or writing GDScript, you have
|
||
crossed the line. Stop and go back to the question you were answering.
|
||
|
||
`crates/sylpheed-viewer` is also **not yours to change** for this objective. The
|
||
Explorer is the human's tool for exploring and verifying the RE work, it keeps its
|
||
static-data-only rule, and the port does not depend on it.
|
||
|
||
## The target
|
||
|
||
Someone else has to build this, from your answers alone:
|
||
|
||
```
|
||
developer logo splash → intro video → title / PRESS Ⓐ → main menu → submenus
|
||
```
|
||
|
||
No gameplay, no 3D, no HUD, no missions. If an answer is not needed to put those
|
||
five screens on a display and let a person move through them with a d-pad and Ⓐ,
|
||
it is not in this objective.
|
||
|
||
## What is already answered
|
||
|
||
Do not re-derive these. They are in `docs/re/` and the
|
||
[disc atlas](../re/disc-atlas.html):
|
||
|
||
* **The screen archive.** `GP_TITLE.pak` holds the whole title-side tree — build 4
|
||
the title with animating wordmarks, build 5 the five-button main menu, builds
|
||
6/8/9 submenus, and the developer splash as the `palogo` bundle in the same pak.
|
||
* **Buttons are identifiable as data.** Element kind `0x3002` is a button, `0x0`
|
||
decoration, `0x10` a primitive; buttons sort top-to-bottom by resting Y; each
|
||
pairs with an `f`-suffixed highlighted variant.
|
||
* **The screen vocabulary.** The GamePart id table, 29 entries at `.rdata
|
||
0x820A1630`, confirmed by the executable's own factory-registration strings.
|
||
* **The resting pose rule** — the hold, not the longest dwell — and that a
|
||
keyframe is the *start of a ramp*.
|
||
* **Screen composition**, pixel-accurate for the tutorial pause menu and the title
|
||
main menu, via `sylpheed-cli screen render`.
|
||
* **The logo splash is not a video.** `logo1`–`logo4` are manifest-bound with no
|
||
`.wmv` on the disc; the splash is the RATC screen, which already renders.
|
||
|
||
## The open questions — these are the objective
|
||
|
||
Ordered by what blocks the port earliest. Each is done when its **gate** exists:
|
||
a written `docs/re/` result with the evidence, and reference data committed
|
||
alongside it.
|
||
|
||
| | Question | Gate |
|
||
|---|---|---|
|
||
| **Q1** | **What is a keyframe time?** Values run 16…269. 60 Hz frames would make the title intro ~4.5 s — plausible and untested. Also: is the ramp linear, or eased? | A measured answer against the running game, not an inference. Everything animated downstream depends on this number |
|
||
| **Q2** | **Which build is which screen state?** Confirm build↔state for splash, title/PRESS Ⓐ, main menu and each submenu | A table, each row confirmed against a capture of the real screen |
|
||
| **Q3** | **Paint order for these six screens.** Solved at runtime, unsolved from the file — the declaration table is provably not it | Either a rule derived from the bundle, or six measured orders and a clear statement that no file-side rule was found |
|
||
| **Q4** | **What does each button do?** Labels are baked into the sprites; no decoded field says which GamePart a button opens | Button → GamePart id, from code or from driving the game. Say which |
|
||
| **Q5** | **Navigation semantics.** Initial focus, wrap-around at the ends, whether left/right does anything, what B does on each screen | Observed behaviour, per screen |
|
||
| **Q6** | **The boot sequence, and what drives it.** Order is observable; the *data or code* that sequences it is not decoded. Include the attract loop and what returns to the title | The sequence, plus whatever the game reads to decide it |
|
||
| **Q7** | **Transitions.** What happens visually between screens — the `pteff00.prm` quads, a fade, a cut — and its timing | Described and timed against a capture |
|
||
| **Q8** | **Menu audio.** Which BGM per screen; which cue on move / confirm / back / error. The cue table is complete; the event binding is not | Cue names bound to events, with how you established each |
|
||
| **Q9** | **Video binding.** Which movie is the boot intro vs the new-game intro; whether playback is skippable and what ends it | Named movies plus the playback rules |
|
||
| **Q10** | **What are a music bank's sub-waves?** `BGM_001.slb` is three sub-waves — 10 KB, 4.47 MB, 4.67 MB — and we currently **concatenate them blindly** into one 347 s track. Two near-equal halves could be intro + loop, or two variations, or two halves of one piece. A menu that loops its music needs to know which | The role of each sub-wave, established for at least the menu BGM. "Concatenate" is a decision, not a default — right now it is a default nobody chose |
|
||
| **S1** | **Ready Room probe.** *Gated* — one iteration, then stop | A written go/no-go (see below) |
|
||
|
||
## Known unknowns — say so, do not fill them in
|
||
|
||
Some of these may turn out to be undecodable. That is a valid, useful answer, and
|
||
it is better than a guess, because the port agent will otherwise have to author
|
||
the mapping by hand and needs to know it is authoring rather than transcribing.
|
||
|
||
For each question, the answer is one of:
|
||
|
||
* **decoded** — here is the field, here is the disc-wide check;
|
||
* **measured** — not on the disc in any form we found, but here is what the
|
||
running game does, and here is the capture;
|
||
* **undecodable, with reach** — we looked here, here and here, and this is why it
|
||
is not there.
|
||
|
||
Never a fourth thing. In particular: if Q4 ends as "read the labels off the sprite
|
||
images by eye", say exactly that — it is then an authored mapping on the port
|
||
side, not a disc fact, and mislabelling it would put a guess into the port wearing
|
||
the badge of a measurement.
|
||
|
||
## The Ready Room probe (S1) — one iteration, then stop
|
||
|
||
`GP_READY_ROOM.pak` is the largest UI archive on the disc, 1 106 entries, and only
|
||
**6 of its names resolve**. It is also ISL-scripted. That is either a week or a
|
||
quarter, and one cheap test tells you which.
|
||
|
||
Our screen catalog enumerates bundles by **content**, not by name — `is_build` /
|
||
`is_composable` read the bytes — so unrecoverable *paths* do not necessarily mean
|
||
unrenderable *screens*.
|
||
|
||
```bash
|
||
sylpheed-cli screen list "$SYLPHEED_DISC/dat/GP_READY_ROOM.pak"
|
||
sylpheed-cli screen render --build <n> "$SYLPHEED_DISC/dat/GP_READY_ROOM.pak" /tmp/rr.png
|
||
```
|
||
|
||
Report how many builds it finds, whether any composite looks like a Ready Room,
|
||
and **whether the room is 2D at all** or 3D with a UI overlay — if it is 3D the
|
||
answer is no-go by definition, not "try harder".
|
||
|
||
**Then stop and write the go/no-go.** Do not start Ready Room work on your own
|
||
authority.
|
||
|
||
## Handing it over
|
||
|
||
[`HANDOFF.md`](HANDOFF.md) is the single page the port agent reads. Keep it
|
||
current as you answer questions: it is a summary with links into `docs/re/`, not a
|
||
second copy of the findings. An answer that is not reachable from HANDOFF.md has
|
||
not been delivered.
|
||
|
||
## Out of scope
|
||
|
||
3D, gameplay, HUD, missions, save/load, localisation beyond English, the Godot
|
||
project itself, any asset pipeline, and any archive outside `GP_TITLE`,
|
||
`tables.pak`, `sound.pak` and `dat/movie/` — except for the S1 probe.
|