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.
110 lines
4.8 KiB
Markdown
110 lines
4.8 KiB
Markdown
# ❔ 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](../boot-config-and-gamepart-registry.md)
|
||
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.
|