7156591654
Last iteration I withdrew "a bundle is a palette" because the evidence did not choose between selective activation within one bundle and two compositions shown in sequence. The alternative can be killed from the disc, which I had not tried. Hypothesis 2 needs a bundle declaring the GLOWS WITHOUT THE LOGOS. There is none. Every GP_TITLE entry carrying palogo elements: 10, 13 (publisher twins) palogo_eff0.prm, palogo_sqex, palogo_sqex_eff 11, 14 (developer twins) palogo_eff0.prm + all three logos + all three glows Four entries, and each developer entry declares the complete set of six. So whichever bundle was active across frames 94-211 -- entry 11, entry 14, or both in turn -- it declared the logos and the glows, while the game drew two sprites at a time in disjoint phases. Therefore only a subset of a bundle's elements is drawn at any moment, whatever the bundle-loading story is. The conclusion no longer depends on resolving how many bundles are involved, which is why the texture-base test's failure stopped mattering. So the claim is reinstated -- this time by eliminating the alternative rather than by assuming it away. What worked was not a better capture but asking what the competing hypothesis would REQUIRE on the disc and finding it absent. METHOD: a hypothesis that predicts an artefact can be killed by looking for the artefact, which is often far cheaper than measuring the behaviour.
182 lines
8.2 KiB
Markdown
182 lines
8.2 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.
|
||
|
||
---
|
||
|
||
## 🔴 Narrowing "a bundle is a palette" — the mechanism is NOT established
|
||
|
||
**2026-08-29.** The glow phase and the logo phase are disjoint, but there are two
|
||
explanations and I asserted one of them:
|
||
|
||
1. **one bundle, selective activation** — the game runs some of entry 11's
|
||
elements, then others;
|
||
2. **two bundle-loads in sequence** — the game shows one composition, then
|
||
another (entries 11 and 14 are twins declaring identical sprites).
|
||
|
||
The draw log records each draw's **texture base**, which looked like it would
|
||
separate them. It does not:
|
||
|
||
| phase | frames | texture bases |
|
||
|---|---|---|
|
||
| publisher splash | 1–90 | `0x11C30000`, `0x10000000` |
|
||
| glows | 94–115 | `0x11C30000`, `0x10000000` |
|
||
| logos | 116–211 | `0x11C30000`, `0x10000000` |
|
||
|
||
**The test fails its own control.** The publisher splash is certainly a different
|
||
bundle from the developer splash — different entry, different artwork — and it
|
||
uses the *same* base. So `0x11C30000` is a reused upload address, not a bundle
|
||
identity, and it cannot distinguish hypothesis 1 from hypothesis 2.
|
||
|
||
### What survives, and what I withdraw
|
||
|
||
✅ **Survives:** a bundle's declared elements are not what gets drawn.
|
||
`palogo_anima` and `palogo_gamearts` carry byte-identical keyframe times, and in
|
||
the same run one is drawn for 95 frames and the other for none — whichever of the
|
||
twins was active declares *both*. The phases are also strictly disjoint (0 frames
|
||
of overlap in 235).
|
||
|
||
🔴 **Withdrawn:** the mechanism. "One bundle, elements activated selectively" was
|
||
my reading, and the evidence does not choose it over "two compositions shown in
|
||
sequence". The practical consequence is the same either way — compositing every
|
||
element of a bundle does not reproduce what the game shows over time — but the
|
||
*why* is not established and should not have been stated as though it were.
|
||
|
||
❔ What would separate them: a per-draw capture recording the **bundle** each draw
|
||
came from, or a kernel/file-IO log showing whether a second RATC entry is read
|
||
between frames 115 and 116.
|
||
|
||
---
|
||
|
||
## ✅ Re-established, by elimination — selective activation is happening
|
||
|
||
**2026-08-29.** The alternative can be killed statically, which I had not tried.
|
||
Hypothesis 2 needs a bundle that declares the **glows without the logos**. There
|
||
is none. Enumerating every entry in `GP_TITLE` that contains `palogo` elements:
|
||
|
||
| entry | elements |
|
||
|---|---|
|
||
| 10, 13 (publisher twins) | `palogo_eff0.prm`, `palogo_sqex`, `palogo_sqex_eff` |
|
||
| 11, 14 (developer twins) | `palogo_eff0.prm`, **all three logos and all three glows** |
|
||
|
||
Four entries, and each developer entry declares the **complete set of six**. So
|
||
whichever bundle was active across frames 94–211 — entry 11, entry 14, or both in
|
||
turn — it declared the logos *and* the glows, while the game drew two sprites at
|
||
a time in disjoint phases.
|
||
|
||
**⇒ Only a subset of a bundle's elements is drawn at any moment, whatever the
|
||
bundle-loading story is.** The conclusion does not depend on resolving how many
|
||
bundles are involved, which is why the texture-base test's failure no longer
|
||
matters.
|
||
|
||
✅ So "a bundle is a palette, not a script" is **reinstated** — this time by
|
||
eliminating the alternative rather than by assuming it away. The route that
|
||
worked was not a better capture but asking what the competing hypothesis would
|
||
*require on the disc*, and finding it absent.
|