acaacc36e0
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
4.0 KiB
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.
⚠️ 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
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