re(ui): deliver the measured splash sequence the port has to author

The activation decision is code, and MISSION already says the port
authors the sequence -- so the useful move is to hand over the sequence
measured rather than chase the code. From the 235-frame draw capture, at
1 frame = 1/30 s (2 units/frame, 1 unit = 1/60 s, both settled in Q1):

  publisher: SQUARE ENIX logo    f1-90     90 frames   3.00 s+   at 0.00
  (gap, nothing drawn)           f91-93     3 frames   0.10 s    at 3.00
  developer: both glows          f94-115   22 frames   0.73 s    at 3.10
  developer: both logos          f116-211  96 frames   3.20 s    at 3.83

Three limits, stated with the numbers rather than after them. The capture
opens with palogo_sqex already at a=255, so the publisher phase began
before the window and 3.00 s is a FLOOR -- every "starts at" is relative
to the capture, not to boot. palogo_anima and palogo_anima_eff get 0
draws in all 214 frames, so a third pair's phase is not in this
measurement. And it is one capture, one run: the glow->logo switch being
a single frame boundary with no overlap is a strong shape, but each
duration is one sample.

What is solid is the part that matters: the 0.73 s and 3.20 s phases are
each within 2% of their element's declared span, so the durations are the
bundle's own and only the ordering is authored. That is the difference
between a port transcribing timing and inventing it.
This commit is contained in:
Sylpheed RE agent
2026-08-29 05:00:54 +00:00
parent 7156591654
commit 7988f52ce7
3 changed files with 52 additions and 0 deletions

View File

@@ -179,3 +179,34 @@ matters.
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.
---
## ✅ The measured splash sequence — what a port has to author
Since the sequencing is not in the placement data, here is the measurement, so a
port authors from evidence rather than from taste. Frames are VdSwap counts;
**1 frame = 1/30 s** (2 units/frame × 1 unit = 1/60 s, both settled in
[Q1](../ui-keyframe-time-unit.md)). Data:
[`data/splash-phase-timeline.txt`](../data/splash-phase-timeline.txt).
| phase | frames | n | seconds | starts at |
|---|---|---|---|---|
| publisher — `palogo_sqex` | 190 | 90 | **3.00+** | 0.00 |
| *(gap — nothing drawn)* | 9193 | 3 | 0.10 | 3.00 |
| developer — **both glows** | 94115 | 22 | **0.73** | 3.10 |
| developer — **both logos** | 116211 | 96 | **3.20** | 3.83 |
⚠️ **Three limits on these numbers.**
* The capture opens at frame 1 with `palogo_sqex` **already at `a=255`**, so the
publisher phase began before the window. **3.00 s is a floor**, and every
"starts at" is relative to the capture, not to boot.
* `palogo_anima` and `palogo_anima_eff` get **0 draws** in all 214 frames, so the
third logo pair's phase — if there is one — is not in this measurement.
* One capture, one run. The glow→logo switch is a single frame boundary with no
overlap, which is a strong shape, but the *durations* are one sample each.
✅ What is solid: the **0.73 s glow phase** and the **3.20 s logo phase** are
each within 2 % of their element's declared span, so the durations are the
bundle's own and only the sequencing is authored.