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:
87
docs/re/structures/boot-splash-dwells-are-declared.md
Normal file
87
docs/re/structures/boot-splash-dwells-are-declared.md
Normal 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
|
||||
```
|
||||
Reference in New Issue
Block a user