baed44a9ea
Two checks on last iteration's "sequential, not simultaneous" reading. First, the phases really are disjoint. If glows and logos ever shared a frame the claim would be wrong. Across all 235 captured frames the count of frames containing both is ZERO, and the switch is a single clean boundary -- f110-115 draw 1280x720 + 262x108 + 525x90, f116 onward 1280x720 + 243x86 + 499x72. Two sprites either side, no transition frame. Second, and larger: a third of the bundle is never drawn. Entry 11 declares three logo/glow pairs and only two appear. palogo_gamearts / _eff 95 / 22 frames palogo_seta / _eff 95 / 22 frames palogo_anima / _eff never palogo_anima declares the SAME keyframe times as palogo_gamearts. Two elements with byte-identical data, 95 frames and 0 frames in one run. Reach: the capture covers frames 1-214, so this is "never in the window". So a bundle is a palette, not a script. Its elements say what to draw and for how long; which of them run, and when each starts, is decided outside the placement data. That is the same conclusion the boot-order work reached from the other end -- the driver is code, not data -- now with a per-element measurement behind it. For the port, concretely: compositing every element of a bundle does not reproduce what the game shows over time. It is the right thing for a static screen that settles, and it is not a timeline. METHOD: two elements with identical data and different outcomes is the strongest possible evidence that the decision is elsewhere.
4.8 KiB
❔ A group's DURATION is in the data; its START TIME is not
Status: ✅ the durations are measured and match; ❔ the start offset is undecodable from the placement data, with the obvious candidate refuted.
Found while testing whether the splash timeline, played, reproduces the capture sequence — the last gap in the animation model.
The durations are right
From the 235-frame draw capture of the developer splash, at the settled 2 units/frame, under the shifted time reading:
| element | drawn on frames | = units | declared visible span | match |
|---|---|---|---|---|
palogo_gamearts_eff, palogo_seta_eff |
94–115 (22) | 44 | ~0 … 45 = 45 | 97.8 % |
palogo_gamearts, palogo_seta |
116–211 (96) | 192 | 15 … 210 = 195 | 98.5 % |
(The logos are a = 0 until t=15, so they are drawn for 15…210; the glows fade
in from their untimed first keyframe.) Each element is on screen for its
declared span, to within 2 %.
🔴 But they do not share a clock origin
Every glow declares the same times — 15, 30, 45 — and every logo the same
15, 30, 190, 194, 206, 210. On one clock they would overlap almost entirely:
both families start at 15.
They do not overlap at all. The glows run frames 94–115 and the logos
116–211 — strictly sequential, the logos starting the frame after the glows
end. Fitting a single origin bears this out: gamearts_eff needs f₀ ≈ 93.5 and
gamearts needs f₀ ≈ 103, about 19 units apart, and the same edit that
aligns one throws the other off by ~9 frames at both ends.
🔴 The obvious candidate is refuted
parse_placements reads each group header as (element index, keyframe count)
followed by one undecoded lead-in word. That is exactly where a per-group
start offset would live. It is 0x00000000 for all seven elements of the
developer splash — glows and logos alike. It carries no offset.
❔ So where does the start come from?
Not from the keyframe times (identical across each family), not from the group
header's spare word (zero), and not from declaration order (eff0.prm, gamearts,
gamearts_eff, seta, seta_eff, anima, anima_eff — which interleaves logos and
glows, while the observed sequencing groups them). The RATC child order does not
match the observed order either.
Reach: three places looked, all negative. What remains is that the sequencing is driven by code, consistent with what boot-config-and-gamepart-registry already concluded for the boot order — the driver is code, not data.
⚠️ What a port needs to know
A group tells you how long an element's animation runs and what it does; it does not tell you when that animation starts relative to other elements on the same screen. On the developer splash the observed order is: both glows together, then both logos together. That is a measured sequence for one screen, not a decoded rule — a port animating a screen has to author the sequencing, and should know it is authoring.
✅ Verified against its own refutation — and it goes further than start times
2026-08-29. Two checks on the "sequential, not simultaneous" reading.
The phases really are disjoint
If the glows and logos ever shared a frame, the sequencing claim would be wrong. Across all 235 captured frames, the number of frames containing both a glow and a logo is zero. The switch is a single clean boundary:
f110–115 1280x720 + 262x108 + 525x90 ← both glows
f116–122 1280x720 + 243x86 + 499x72 ← both logos
Two sprites either side, no overlap, no transition frame.
A third of the bundle is never drawn at all
Entry 11 declares three logo/glow pairs. Only two are ever drawn:
| sprite | declared | drawn |
|---|---|---|
palogo_gamearts / _eff |
500×71 / 521×91 | 95 / 22 frames |
palogo_seta / _eff |
240×89 / 261×110 | 95 / 22 frames |
palogo_anima / _eff |
388×136 / 407×156 | never |
…and palogo_anima declares the same keyframe times as palogo_gamearts.
⚠️ Reach: the capture covers frames 1–214, so this is "never within the
window", not "never". The pair may follow after it.
What that means for a consumer
A bundle is a palette, not a script. Its elements carry what to draw and for how long; which of them run, and when each starts, is decided outside the placement data — selectively enough that two elements with byte-identical keyframe times get 95 frames and 0 frames in the same run.
That is the same conclusion the boot-order work reached from the other end (the driver is code, not data), now with a per-element measurement behind it.
⚠️ Concretely: compositing every element of a bundle does not reproduce what the game shows over time. It is the right thing for a static screen that settles, and it is not a timeline.