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:
Sylpheed RE agent
2026-08-29 04:47:05 +00:00
parent 7fb6bdfad8
commit baed44a9ea
4 changed files with 72 additions and 0 deletions

View File

@@ -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:
```
f110115 1280x720 + 262x108 + 525x90 ← both glows
f116122 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 1214, 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.