re: the boot splash dwells are declared -- and wall clock is the wrong unit

The port asked for two wall-clock timestamps across the boot splashes. Measured,
and the measurement's own result is that timestamps are not the invariant.

The dwells are the bundles' own declared timelines: publisher t=0..255 = 4.250 s
at 60 units/s, developer t=0..210 = 3.500 s. The corpus's independent screenshot
timing over three cold boots gives 4.30/4.60/4.37 and 3.51/3.50/3.37 -- the
developer agreeing to 1.1%, two of its three runs to 0.3%.

A fresh no-input boot with a frame->wall-clock map puts the same two dwells at
5.10-5.61 s and 3.83-4.30 s, 15-20% longer than both the declared values and the
corpus's runs, on the same disc and the same declared timeline. So the
wall-clock dwell is an emulator-pacing artefact that varies run to run, and a
port authoring seconds is authoring one run's pacing.

Boundaries from the draw stream, read per quad: publisher glow frame 1, wordmark
6-119, three frames with NO sprite drawn, developer glows 123, wordmarks
140-209, intro video 216. The 3-frame gap replicates the earlier 4-frame
measurement within the +-1 both are quantised to.

New tool frame_clock.sh, and its limitation found by its own control: it
resolves to one BUFFER FLUSH, not one frame. The capture writes through a C++
ofstream, so tail sees the log in bursts -- 69 of 125 samples showed no advance
and the rest jumped 7-15 frames. Naive interpolation inside a burst made the
apparent rate swing between 0.0164 and 0.0316 s/frame, which is the flush and
not the guest. Frames 119 and 123 fall in one burst, so the inter-splash gap is
not separable by this clock at all. Everything is quoted as brackets and the
point estimates were withdrawn before being reported.

palogo_anima never appears in the log and is NOT reported as undrawn: the
developer bundle batches 7 elements into one draw and only the first two quads
are logged. That is the trap that produced the eff3 false negative, so it is
named rather than claimed.

Also records the port's correction: ptcopyright has 105 instants with alpha >= 1
(t=139..243) against 105.89 units of span; I had quoted the rounded span.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 21:29:06 +00:00
parent 78328c5022
commit acaacc36e0
4 changed files with 176 additions and 0 deletions

View File

@@ -0,0 +1,87 @@
# The boot splash dwells are declared on the disc — wall clock is the wrong unit
**Classification: decoded**, with an independent wall-clock check. The port asked
for two timestamps; the right answer is that timestamps are not the invariant.
## The answer
| splash | bundle | declared timeline | at 60 units/s | corpus wall clock, 3 cold boots | error |
|---|---|---|---|---|---|
| publisher | `GP_TITLE` entries 10, 13 | t = 0 … **255** | **4.250 s** | 4.30 / 4.60 / 4.37 | 4.1 % |
| developer | entries 11, 14 | t = 0 … **210** | **3.500 s** | 3.51 / 3.50 / 3.37 | 1.1 % |
The developer splash is the sharp one: **3.500 s declared against 3.51 and 3.50
measured** on two of three boots. **Author the units.**
## Why not seconds — this run is the argument
A fresh no-input boot with a frame→wall-clock map (below) puts the same two dwells
at **5.10 – 5.61 s** and **3.83 – 4.30 s** — **15–20 % longer** than both the
declared values and the corpus's three runs, on the same disc and the same
declared timeline.
**So the wall-clock dwell is an emulator-pacing artefact that varies run to run.**
Three separate measurements of this container's rate — 13.1 fps, ~28 fps, and this
one — say the same thing from another direction. A port that authors seconds is
authoring one run's pacing.
## The boundaries, from the draw stream
Read with the per-quad parser, this boot:
| event | frame |
|---|---|
| `palogo_sqex_eff` — the publisher's glow | 1 |
| `palogo_sqex` — the wordmark | **6** – 119 |
| no sprite drawn at all | 120 – 122 |
| `gamearts_eff` + `seta_eff` — the developer's glows | **123** – 139 |
| `palogo_gamearts` + `palogo_seta` — the wordmarks | 140 – 209 |
| intro video (a 640×360 pair per frame) | **216** – 563 |
The 3-frame black gap replicates the 4-frame gap measured in the earlier boot,
within the ±1 frame both are quantised to — consistent with the ~9 units in
[`boot-splash-gap-measured.md`](boot-splash-gap-measured.md).
⚠️ **`palogo_anima` never appears**, and that is almost certainly the 8-vertex cap
rather than a fact about the game: the developer bundle has 7 elements batched into
one draw, and only the first two quads are logged. This is the trap that produced
the `eff3` false negative, so it is named rather than reported.
## 🔴 The instrument's resolution is one buffer flush, not one frame
`tools/re-capture/frame_clock.sh` polls the growing draw log for its last frame
number. The capture writes through a C++ `ofstream`, so `tail` sees the file in
flush-sized bursts:
* **69 of 125 samples showed no advance at all**; the rest jumped **7–15 frames**
at once.
* Interpolating a frame's time *inside* a burst invents precision. Done naively it
made the apparent rate swing between **0.0164 and 0.0316 s/frame** — 61 fps to
31 fps — which is the flush, not the guest.
* **Frames 119 and 123 fall in the same burst**, so the black gap between the
splashes is **not separable by this instrument at all**. Its duration here comes
from frame counting, not from this clock.
So the table above is quoted as **brackets**: a frame's true time lies between the
last sample that had not reached it and the first that had. Sub-flush point
estimates are not available and were withdrawn before being reported.
## What is still open
❔ The publisher's 4.1 % error against its declared 4.250 s is larger than the
developer's 1.1 %, across only three corpus boots plus this one. Whether that is
run-to-run pacing or something the publisher splash does differently is not
settled.
⚠️ The intro-video boundary (frame 216) is 7 frames after the developer splash's
last draw, but those 7 frames span **1.77 s** by the naive map — deep inside the
flush artefact, and the movie is loading there. **The developer→intro gap is not
measured**, only bounded at 5.70 – 6.21 s end to end.
## Reproducing
```bash
GRACE=1 NOTAP=1 FRAMES=9000 ARM=early tools/re-capture/ui_draw_capture.sh 200 /tmp/cap &
tools/re-capture/frame_clock.sh /tmp/cap/xenia_re_ui_draws_01.log /tmp/cap/frameclock.tsv \
150 0.2 /tmp/cap/canary.stdout 400
```