Closing the caveat I left last iteration -- the splash timing was +/-0.5s because I sampled at 2 fps, and at that rate I could not see ramps at all, only plateaus. Re-recorded at 10 fps: the splash FADES, both in and out, rather than cutting. And the bundles declare it. palogo_sqex.t32 carries keyframes [15 30 235 239 251 255] and palogo_gamearts.t32 [15 30 190 194 206 210], each with an _eff glow child on [15 30 45]. Under Q1's 1 unit = 1/60 s that is a 0.25 s ramp in, a 3.42 s or 2.67 s hold, and a 0.33 s fade out -- against measured holds of about 3.5 s and 2.4 s and fade-outs of about 0.3 s. The constant 0.35 s offset between declared and measured start is just that my recording's t=0 is when the WINDOW appears, not when the guest starts drawing. So the first screen's animation moves from measured to decoded: the port reads it off the disc instead of trusting my stopwatch. It also explains something the capture showed and I had no account for. The brightness overshoots on the way in -- peaks at 0.8 s, settles by 1.1 s -- which reads as a bloom. It is the _eff glow child, whose keyframes run 15 -> 30 -> 45, ramping in after the logo and back down while the logo holds. Mechanical, not a rendering artifact.
10 KiB
Which GP_TITLE build is which screen — measured against the running game
Status: ✅ CONFIRMED for the four screens the boot path actually shows
(title art, PRESS Ⓐ BUTTON, main menu, EXTRAS); 🟡 PROBABLE for their
Japanese twins; ❔ open for the two DELTASABER plates.
Answers MISSION Q2. The previous statement — "build 4
title, 5 main menu, 6/8/9 submenus" — is partly wrong and is withdrawn:
build 8 is the Japanese main menu, not a submenu, and GP_TITLE holds
exactly one submenu (EXTRAS), in two languages.
The archive is eight screens, each shipped twice
GP_TITLE.pak has 16 entries; sylpheed-cli screen list calls 12 of them
composable builds. The 16 fall into eight pairs, and each pair's two members
have near-identical sizes and name hashes that differ by a constant — one
character of the name apart:
| entry | hash | bytes | build idx | pair |
|---|---|---|---|---|
| 0 | 01a2db9c |
483 958 | 0 | A |
| 1 | 0ff0b8a8 |
483 958 | 1 | A |
| 2 | 285d8849 |
267 014 | 2 | B |
| 3 | 369773cb |
267 014 | 3 | B |
| 4 | a60fcb85 |
12 278 666 | 4 | C |
| 7 | b483e6e6 |
13 363 328 | 7 | C |
| 5 | a715f485 |
6 977 437 | 5 | D |
| 8 | b58a0fe6 |
6 931 653 | 8 | D |
| 6 | a81c1d85 |
6 549 126 | 6 | E |
| 9 | b69038e6 |
6 548 438 | 9 | E |
| 10 | cdba806e |
426 473 | — | F |
| 13 | db2ea1f8 |
423 333 | — | F |
| 11 | cec0a96e |
999 643 | — | G |
| 14 | dc34caf8 |
999 643 | — | G |
| 12 | cf2a8ccd |
1 774 639 | 10 | H |
| 15 | dd56d99b |
1 774 639 | 11 | H |
For the three pairs whose members differ visibly — C, D, E — the difference is
English versus Japanese: build 7 is the title art with the katakana subtitle
プロジェクト シルフィード, build 8 the main menu reading 新規 / ロード /
チュートリアル / オプション / エクストラ, build 9 the EXTRAS submenu as
エクストラ. That is the whole of the language split we can see. In pairs A, B and
H the two members render byte-identical PNGs — the archive still carries two
copies, but the artwork does not change with the language.
Pairs F and G are the four entries screen list does not classify as builds by
default. They are the developer splash, and they render — see below.
The map
Contact sheet of every render:
captures/title-builds/title-build-contact-sheet.png.
| build | what it is | confirmed how |
|---|---|---|
| 0, 1 | a DELTASABER / SYLPHEED A.I. plate low-left on black, no background |
❔ not observed running. Never seen in the boot path, the main menu, EXTRAS or MISSION SELECT |
| 2, 3 | the PRESS Ⓐ BUTTON plate — an overlay build of its own, not a state of build 4 |
✅ seen composited over build 4 on the live title, at the same rect our render puts it |
| 4 | title art, English (PROJECT SYLPHEED, ™, (C)2006,2007 SQUARE ENIX) |
✅ live-title-press-a.png |
| 7 | the same, Japanese | 🟡 renders as the JP twin of build 4; the container runs an English locale, so it was not seen |
| 5 | main menu, English: NEW GAME / LOAD GAME / TUTORIAL / OPTIONS / EXTRAS, footer Ⓐ : OK |
✅ live-main-menu.png — element for element |
| 8 | the same, Japanese | 🟡 as above |
| 6 | the EXTRAS submenu, English: MISSION SELECT / MOVIE THEATER / BACK, footer Ⓐ : OK Ⓑ : Back |
✅ live-extras.png |
| 9 | the same, Japanese | 🟡 as above |
| 10, 11 | the same DELTASABER plate as build 0, over a dark circuit-line background |
❔ not observed running |
✅ The splash — the four "non-build" entries, rendered
screen list --all widens the enumeration to every composable bundle and shows
all 16 entries. The four that the default listing drops are the two halves of
the developer splash, each shipped twice:
| entry | elements / sprites | what it is |
|---|---|---|
| 10, 13 | 3 / 2 | the white SQUARE ENIX publisher logo |
| 11, 14 | 7 / 6 | GAME ARTS / SETA / studio anima — the developer logos |
splash-entries-rendered.png.
Rendered with screen render --all --primitives --black. Entry 11's seven
elements are the three logos, their three _eff glows and the
palogo_eff0.prm black backdrop — exactly the composition
structures/ui-paint-order-key.md measured
for the splash.
✅ Confirmed against the running game — 2026-08-28
The 🟡 above ("no framebuffer capture to diff against") is closed. Recording the
boot from the moment the window appears, at 2 fps, catches the splash before the
movie:
live-splash-publisher.png,
live-splash-developer.png.
Edge-correlated against the renders, with the other half as a negative control:
| capture | vs entry 10 | vs entry 11 |
|---|---|---|
| publisher frame (t ≈ 2.0 s) | 0.9146 @ (0,0) | 0.027 ✗ |
| developer frame (t ≈ 6.0 s) | −0.033 ✗ | 0.9792 @ (0,0) |
Both halves match their own render at zero shift and are firmly rejected by the
other. The 13/14 twins score 0.876 / 0.966 — near-identical artwork, so this
test cannot tell a pair apart, only a screen from a different screen.
✅ The splash's timing is DECODED, and the capture confirms it
Re-recorded at 10 fps (the 2 fps pass below was ±0.5 s and could not see ramps at all). The splash fades, both ways — it does not cut — and the bundle's own keyframes say so:
$ sylpheed-cli screen info --all --build 10 GP_TITLE.pak
1 palogo_sqex.t32 7 kf [15 30 235 239 251 255 -]
2 palogo_sqex_eff.t32 4 kf [15 30 45 -] (the glow, child of 1)
$ ... --build 11
1 palogo_gamearts.t32 7 kf [15 30 190 194 206 210 -] (seta, anima identical)
2 palogo_gamearts_eff 4 kf [15 30 45 -]
Under Q1's 1 unit = 1/60 s:
| declared | measured at 10 fps | |
|---|---|---|
SQUARE ENIX ramp in |
15 → 30 = 0.25 s |
rise 0.4 → 0.8 s |
SQUARE ENIX hold |
30 → 235 = 3.42 s |
≈ 3.5 s (0.8 → 4.3 s) |
SQUARE ENIX fade out |
235 → 255 = 0.33 s |
≈ 0.3 s (4.4 → 4.7 s) |
| developer hold | 30 → 190 = 2.67 s |
≈ 2.4 s (5.6 → 8.0 s) |
| developer fade out | 190 → 210 = 0.33 s |
≈ 0.3 s (8.1 → 8.4 s) |
The offset between declared and measured start is ≈ 0.35 s, which is simply that
the recording's t = 0 is when the window appears, not when the guest starts
drawing. Everything downstream of that lines up.
The overshoot is the glow. The measured rise peaks (6.21) at 0.8 s and settles
back (5.39) by 1.1 s, which looks like a bloom. It is the _eff child element:
its keyframes are 15 → 30 → 45, so it ramps in after the logo and then back
down, while the logo itself holds. Decoded, not a rendering artifact.
So the port can read the splash's timing off the disc rather than author it — the first screen's animation is not a measurement it has to trust.
The wall-clock sequence, for orientation
SQUARE ENIX on screen |
≈ 0.5 → 4.0 s after the window appears |
| black | ≈ 4.5 s |
GAME ARTS / SETA / studio anima |
≈ 5.0 → 7.5 s |
| black | ≈ 9.0 s |
ADV.wmv begins |
≈ 9.5 s |
⚠️ The frames at ≈ 9.5–12.5 s show SQUARE ENIX again in cyan. That is not a
third splash — it is the intro movie's own opening, which the milestone-2 notes
describe as "white SQUARE ENIX + cyan glow + red diamonds". A capture-only reading
would have recorded a third logo screen that does not exist.
So the first of the five screens now has a reference composite, a framebuffer capture, and its on-screen durations.
Reach of the two negatives. Builds 0/1 and 10/11 were looked for in: the whole
boot sequence (a 5 s-cadence filmstrip from launch to the title, ~190 s), the
title, the main menu, the EXTRAS submenu, the LOAD GAME slot list, the
transition into MISSION SELECT (a 40-frame burst), and the attract cycle. They
appear in none of them. The obvious remaining candidate is a long load — a
mission launch — which is out of this objective's scope; they are most likely a
loading/AI-chatter plate. That is a hypothesis, not a result.
Three things the captures settle beyond the map
The live title is two builds composited. Build 4 draws the art; build 2 draws
PRESS Ⓐ BUTTON on top, and it fades in a beat later — a screenshot taken
2.5 s after arriving at the title has the art and no plate, one taken ~1 s later
has both. The port must treat the plate as its own timed element.
The attract-loop title carries the plate too. After ~8–10 s idle the title
fades to black, a full-motion video plays for ~85 s, and the title comes back —
with PRESS Ⓐ BUTTON
(live-attract-title-press-a-band.png).
This is consistent with, and adds nothing to, the draw-quad comparison in
canary-scripted-input-traps.md: the plate is
not the tell that distinguishes the boot title from the attract title.
EXTRAS is the only main-menu destination inside GP_TITLE. Ⓐ on EXTRAS
opens build 6 — measured. The other four destinations leave the archive: Ⓐ on
LOAD GAME opened a LOAD GAME slot list, and Ⓐ on MISSION SELECT inside
EXTRAS opened a MISSION SELECT screen, neither of which is a GP_TITLE
build. dat/ carries GP_SAVE_LOAD.pak, GP_TUTORIAL.pak, GP_OPTIONS.pak,
GP_MISSION_SELECT.pak and GP_MOVIE_THEATER.pak; that those are the archives
behind the other four buttons is an inference from the names, not a measurement.
How to reproduce
sylpheed-cli screen list "$SYLPHEED_DISC/dat/GP_TITLE.pak"
sylpheed-cli screen render --build 6 "$SYLPHEED_DISC/dat/GP_TITLE.pak" /tmp/b6.png
tools/re-capture/boot_menu.sh q2 # boots to the main menu, cursor on NEW GAME
tools/re-capture/pad.py dpad down 0.35 # x4 -> EXTRAS
tools/re-capture/pad.py tap A 0.30
Mind the d-pad hold — see METHOD.md.