Sylpheed/docs/re/splash-declared-vs-captured.md

The declared timeline does reproduce the captured splash — and the unit rate is per-GamePart

Status: ✅ two results, one of which corrects me. 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), 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).

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. 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 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 GameParts, 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.