# The declared timeline **does** reproduce the captured splash

**Status: ✅ §1 stands. ❌ §2 is WITHDRAWN** — see
[`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The rate claim was the
emulator's frame rate; the timeline result never divides by a duration and is
unaffected. 2026-09-01.
Instrument: ⟨disc⟩ for the declared side, ⟨capture⟩ for the observed side.
**No renderer is anywhere in this comparison** — it is a keyframe table against a
vertex stream.

Settles the R1-re-opened entry *"the declared keyframe timeline reproduces the
captured splash"*, 🟡 `⟨our-reader⟩`, whose stated condition was *"re-derive the
declared timeline under the fixed record layout and re-compare against the same
frames."*

---

## 1 ✅ The declared timeline reproduces the capture to **one alpha level**

Declared, off the disc ([`data/splash-declared-timeline.txt`](data/splash-declared-timeline.txt)),
`GP_TITLE` build 11:

| family | declared keyframes |
|---|---|
| logos (`palogo_gamearts`, `_seta`, `_anima`) | `0:a=0  15:a=0  30:a=255  190:a=255  194:a=232  206:a=32  210:a=0` |
| glows (`_gamearts_eff`, `_seta_eff`) | `0:a=0  15:a=255  30:a=255  45:a=0` |
| `palogo_anima_eff` | `0:a=0  15:a=255  **30:a=212**  45:a=0` |

Captured: the per-quad vertex alphas from the draw stream
([`data/splash-quad-timeline.txt`](data/splash-quad-timeline.txt)).

**Test — deliberately calibration-free.** No fitting, no clock, no lag search:
*is each captured alpha an exact member of the declared value set*, i.e. equal to
the declared piecewise-linear α(t) at some integer t?

| | |
|---|---|
| samples | **50** |
| exact members under **truncation** | **39 / 50** |
| exact members under **rounding** | 30 / 50 |
| **worst error under either rule** | **1 alpha level out of 255 — 0.39 %** |
| samples off by more than one level | **0** |

**Every one of the 11 non-exact samples is low by exactly 1**, and every one of
them is on a *falling* segment. Truncation fits better than rounding by 9
samples, which is what an integer interpolator that floors rather than rounds
looks like.

📌 **So the entry resolves in favour of the declared timeline.** The old ❌ rested
on *"`palogo_gamearts` is still at `a=255` nine frames after its declared
`a=32`"* — under the fixed record layout `a=32` is at **t=206**, four units from
the end of a 210-unit timeline, not early. That was the off-by-one association,
exactly as the R1 note suspected.

🟡 **What is not settled:** *why* 11 samples floor one low while 39 do not. The
residual is one level and is named, not hidden. A candidate is that the clock is
fractional and α is floored, so a sample lands one low whenever the fraction is
small — untested.

## 2 ❌ WITHDRAWN — "the unit→seconds rate is per-GamePart"

> 🔴 **This section is REFUTED and is kept only for the record.** See
> [`splash-rate-withdrawn.md`](splash-rate-withdrawn.md). The three "rates" below
> came from three regions of one run at **3.39 / 15.33 / 23.20 labels per guest
> second**, and the reported rates order the same way — 35 / 40 / 57. It is the
> emulator's pacing, not the `GamePart`. The corpus already documented the effect
> in `boot-splash-dwells-are-declared.md`; I re-derived it as a discovery and drew
> a false conclusion from it. **The rate is 60 units/s for every screen, and §1
> above is untouched.**

### the withdrawn text follows

#### (withdrawn)  The unit→seconds rate is **per-GamePart**, and I told the port otherwise

This is the correction, and it matters more than the first result.

An hour ago I reported **56.8 units per guest second** off the plate and wrote
that the reach was the title. The splash now has its own measurement, from the
disc-declared `T` rather than a borrowed one, and **it is a different number.**

| screen | element | declared | measured | **units / guest second** |
|---|---|---|---|---|
| title | `ptbtn00` ramp | `T = 22` (`t=214→236`, ⟨disc⟩) | 657.9 α/s | **56.8** |
| title | `ptcopyright` ramp | implied `T = 22.25` | 650.4 α/s | 56.8 (control, 1.15 %) |
| splash | `palogo_gamearts` ramp | `T = 15` (`t=15→30`, ⟨disc⟩) | 664.8 α/s | **39.1** |
| splash | publisher logo ramp | `T = 15` ⟨disc⟩ | 679.4 α/s | **40.0** |
| **splash** | **`palogo_gamearts` HOLD** | **160 units (`t=30→190`) ⟨disc⟩** | 4.514 guest s | **35.4** |

### The hold is what makes this safe to say

A ramp rate is `(Δα/Δt) × T/255` and therefore depends on `T`. **The hold does
not.** It is a declared *duration* — 160 units of plateau — measured directly in
guest seconds, with no alpha slope, no interpolation and no `T` in the
arithmetic. It gives **35.4 units/s** against the same screen's ramp at 39.1, and
the two share none of their algebra.

⚠️ The hold figure is a **lower bound on the rate**: it is measured between the
first and last labels at α=255, and the true plateau extends slightly past both.
So the splash sits at **~35–40 units/s** and the title at **~57**.

### Why I nearly missed it — recorded because it is a good trap

All four elements give **650–679 α/s**, agreeing to ±2 %, which reads exactly
like one clock. It is a coincidence: `T` differs 22 vs 15 (ratio 1.47) and the
rates differ 57 vs 37 (ratio 1.54), and those two ratios nearly cancel in
`Δα/Δt`. **A quantity that looks constant across screens is not evidence of one
clock when the thing that would vary is inside it.** The hold breaks the tie
because `T` is not in it.

### And my "borrowed `T=15` does not apply" was wrong

[`units-per-second-measured.md`](units-per-second-measured.md) says the splash
elements' implied `T` is 23–34, *"none of them 15"*, derived by assuming one
rate. **The disc says `T = 15`, plainly.** The premise was the single rate, not
the `T`. Both halves of that page's arithmetic were right and its conclusion
about which term was unknown was wrong.

## What this means for the port

🔴 **A single `keyframe_units_per_second` cannot be right.** The two splashes and
the title run their timelines at rates ~1.5× apart, and the splashes are exactly
the screens the play-test called *"close but not right"*.

* title: **~57 units/s** — the port's 60 is 5 % away and stands.
* splashes: **~35–40 units/s** — a port running them at 60 plays them **1.5–1.7×
  too fast**, which would make every splash fade look shorter and sharper than
  the game's. That is the direction of *"the fade is more pronounced in the
  game"*.

**Classified: measured**, not decoded. Nothing on the disc has been found that
*states* a rate; these are two numbers off the running game. The port authors
them and must know it is authoring.

## Reach

Two `GamePart`s, one boot each. It establishes that the rate is **not global**,
which is a negative with wide reach — one counter-example is enough. It does
**not** establish the rate for the main menu, `EXTRAS`, or any submenu, and those
must not inherit either number. ❔ Where the rate comes from — a per-`GamePart`
field, a constant in the driver, or a frame-rate target — is **not decoded**, and
that is the next question.