7fb6bdfad8
Tested whether the splash timeline, played, reproduces the capture -- the last gap in the animation model. Half of it does. Durations match. At 2 units/frame under the shifted reading, from the 235-frame draw capture of the developer splash: glows drawn f94-115 (22 frames = 44 units) declared ~0..45 = 45 97.8% logos drawn f116-211 (96 frames = 192 units) declared 15..210 = 195 98.5% Each element is on screen for its declared span to within 2%. Starts do not. Every glow declares the same times 15,30,45 and every logo the same 15,30,190,194,206,210, so on one clock they would overlap almost entirely -- and they do not overlap at all. The glows run 94-115 and the logos 116-211, strictly sequential, the logos starting the frame after the glows end. Fitting one origin needs f0 ~ 93.5 for gamearts_eff and ~103 for gamearts, about 19 units apart, and aligning 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) plus one undecoded LEAD-IN WORD -- exactly where a per-group start offset would live. It is 0x00000000 for all seven elements, glows and logos alike. Reach: not the keyframe times (identical within each family), not that word (zero), not declaration order (which interleaves logos and glows where the observed sequencing groups them), not the RATC child order. What remains is that the sequencing is code-driven, which agrees with what the boot-order work concluded independently. For the port: a group says how long an element animates and what it does, not when it starts relative to its neighbours. The observed order on the developer splash -- both glows, then both logos -- is measured for one screen, not a decoded rule, so the sequencing has to be authored. METHOD: when a model reproduces durations but not positions, the missing piece is an origin, not a rate.
3.0 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.