e81dcad632
new-game intro has a name Q9, answered twice over -- once from the disc and once from frames I had already captured and not used. The movie manifest's first eight slots are the whole boot-side flow, and the slot key is the role: LOGO1-4 -> logo1-4.wmv (not on the disc, which is why the splash is a screen), ADVERTISE_MOVIE -> ADV.wmv, STAFF_ROLL -> the credits reel, MS00A -> S00A.wmv, MS01A -> S01A.wmv. So the new-game intro is S00A.wmv, decoded -- which is the half I could not test at runtime, because A on NEW GAME hangs the emulator. And there is no separate boot-intro slot: ADV.wmv IS the advertise movie, the boot just plays it first. Confirmed independently by matching 19 attract frames against five candidates -- 15 hit ADV with a playhead that advances monotonically at the sampling rate and ends at 137 s, its full length, with the title back on the next sample. So the attract movie plays to its end; nothing cuts it short. That corrects me. Two iterations ago I recorded the attract movie as "~85 s, so probably not ADV.wmv" -- arithmetic on a start I never observed, since sampling began 39 s in. REFUTED and METHOD both take it, along with the matcher's real failure mode: a near-black frame has no signature, and its runner-up is not evidence. Skippability I did NOT settle, and the corpus contradicts itself: one page says A skips a movie every time, while the boot harness deliberately never taps during one because it breaks the title. Named the one-boot test rather than picking a side.
5.0 KiB
Which movie plays where — the boot intro, the attract loop, the new-game intro
Status: ✅ CONFIRMED. The bindings are decoded from the movie manifest,
and the attract movie is independently measured from captured frames. One
part — whether playback is skippable — is 🟡 and the corpus contradicts itself
about it; that is written down rather than resolved by assertion.
Answers MISSION Q9, and contributes to Q6.
The manifest names the boot-side slots — decoded
The movie manifest (dat/tables.pak entry 0x5b983a08, schema 0x067025b9,
movie_manifest.rs) is an
array of slots whose key is the semantic role, with a parallel array of value
records in the same order. Its first eight slots are the whole boot-side flow:
| slot key | movie | also bound |
|---|---|---|
LOGO1 … LOGO4 |
logo1.wmv … logo4.wmv |
— |
ADVERTISE_MOVIE |
ADV.wmv |
VOICE_ADV |
STAFF_ROLL |
SYLPH_HD720p_8M-CBR_2ch.wmv |
subtitle table |
MS00A |
S00A.wmv |
SUBTITLE_S00A, VOICE_S00A, a pwterop_s01a.prt overlay |
MS01A |
S01A.wmv |
SUBTITLE_S01A, VOICE_S01A |
The alignment is not in doubt here even though the manifest has valueless slots
elsewhere: logo1..4 zip 1:1 onto LOGO1..4, and MS00A→S00A.wmv,
MS01A→S01A.wmv are the manifest's own anchor rule.
The logo1–logo4 slots are bound to .wmv files that are not on the disc —
already established, and the reason the developer splash is a screen, not a video.
✅ The boot intro and the attract movie are the same asset
There is no separate boot-intro slot. ADV.wmv is bound to
ADVERTISE_MOVIE — it is the advertise movie, and the boot simply plays it
first. For the port that means one video, not two.
Measured independently, from captured frames
Frames captured 5 s apart during an attract cycle were matched against five
candidate movies by frame signature (32×18 normalised grayscale, movie frames
cropped to the 675 of 720 rows the game surface shows, 1 fps sampling).
tools/re-capture/frame_match.py; full table in
data/attract-frame-match.txt.
15 of 19 attract frames matched ADV.wmv, and the matched timestamps advance
monotonically at the sampling rate — 39, 45, 56, 62, 75, 80, 85, 92, 102, 108,
113, 119, 131, 137 s — ending at 137 s, which is ADV.wmv's full length, after
which the title returned. That is not a similarity score, it is a playhead.
The control was run first and behaves the same way. Frames captured during
the boot movie — known to be ADV.wmv — matched ADV at 116, 121, 129, 134 s.
Its failure mode is worth stating: on near-black frames the correlation collapses
(one control frame scored 0.000, another tied S13A 0.984 against ADV 0.926).
Those are exactly the 4 attract frames that did not match. A dark frame carries
no signature; it is not evidence for the runner-up.
🔴 This corrects an earlier claim of mine
Two iterations ago I recorded the attract movie as "≈85 s, so probably not
ADV.wmv's 137 s". That was wrong, and the mistake was arithmetic on an
unobserved start: my sampling began when the movie was already 39 s in, so
what I timed was the tail of it, not the whole thing.
✅ The new-game intro is S00A.wmv
Slot MS00A — the prologue story intro, 93.87 s, with its own subtitle table,
VOICE_S00A, and a text overlay. Decoded from the manifest, not measured:
Ⓐ on NEW GAME hangs the emulator
(menu-navigation-semantics.md), so this
binding has not been watched happening.
🟡 Skippable — the corpus contradicts itself, and I did not settle it
canary-scripted-input-traps.mdstates plainly that "Ⓐ during a movie skips the movie, every time".- But
boot_menu.sh/skip_intro.shas they stand deliberately do not tap during a movie, loggingmovie … -> waiting it out (tapping breaks the title), and the same document records run G: 88 Ⓐ presses through the boot left a permanent black screen.
Both cannot be the whole story. The test: boot, tap Ⓐ exactly once well inside the movie, and record whether the title arrives early. One boot, and it was not run this iteration.
✅ What ends the attract movie
Nothing intervenes: it plays to its end. The last matched frame is ADV at
137 s — the file's full duration — and the title is back on the next sample. So
the attract cycle is: title, idle ~8–10 s, fade to black, ADV.wmv in full, back
to the title (which redraws PRESS Ⓐ BUTTON).
What this contributes to Q6
The manifest is data the game reads to sequence the boot side: the slot keys are in play order and the key is the role. That is not the whole driver — it says what plays, not what decides to advance — but it is the first file-side piece of Q6's second half, and it means the boot-side asset order does not have to be authored.