re(ui): the sequencing survives refutation -- and a bundle is a palette
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.
This commit is contained in:
@@ -60,3 +60,50 @@ 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.
|
||||
|
||||
Reference in New Issue
Block a user