Sylpheed/docs/re/clock-origin-blocked-boot-has-no-title.md

❔ The clock origin is not measurable from a boot capture — the title is not in one

Status: ❔ blocked, with the reach stated. 2026-09-01. Instrument: ⟨capture⟩ ×3. Recorded rather than worked around, per "do not improvise around a blocker".

---

What I set out to do

The clock origin is the last surviving candidate for play-test finding 3. Every quantity in today's account is a ratio or a count, and a common offset survives all of them — if the port's clock starts at a different moment from the game's, every interval matches and the screen still arrives late.

Now that the clock is known to advance 1 unit per present, the origin is directly measurable as a count: observe the plate at a known declared alpha (the 214 → 236 ramp gives t to within one unit), count presents back to the first present on which the title draws anything, and the difference is the title's clock value at its own first draw. Zero means the clock starts when the screen does; anything else is the offset a port must author.

No capture I have contains the plate, or the title at all.

What the boot actually does, measured three times

capture	publisher splash	developer splash	first movie frame
boot 1	presents 1…219 (219)	224…409 (186)	422
boot 2	1…228 (228)	234…418 (185)	429
--framerate_limit=30	1…244 (244)	250…453 (204)	463

Two splashes, then the attract movie. There is no title segment. The two UI-drawing segments are the publisher and developer splashes — identified by their quad rects and by dwells matching boot-order-and-splash-dwell.md — and the next thing to draw is the movie's luma plane.

📌 This is not a new failure; it re-frames an old one as expected. The corpus records "three runs, two locales, two launch paths, ~35 minutes of emulator time, no interactive title", and treats it as an unexplained blocker. The reason is plainer than it looked: MISSION.md's own boot order is splash → intro video → title, ADV.wmv is 137.7 s ⟨disc⟩, and a 600-present capture at ~50 presents/s is ~12 s. The title is on the far side of a two-minute movie. A capture that never reaches it is behaving correctly.

⚠️ These runs use NOTAP=1, which is what the splash work needed and is exactly what prevents skipping the movie.

What would settle it, and neither is free

1. Tap Ⓐ to skip the movie, then capture the title. ui_draw_capture.sh already taps while a movie plays when NOTAP is unset. The risk is documented in that script's own header: a stray Ⓐ on the title sends the guest into the save-data probe, which crashed it on 2026-08-18.
2. Capture through the whole movie — ~137 s at ~50 presents/s is ~6 900 presents, against the 600 these runs used. FRAMES and MAXDRAWS both scale; the log would be ~15 MB, which is fine.

Option 2 needs no pad input and cannot crash the guest, so it is the one to run. I did not run it: it is a single capture but a long one, and I would rather pre-register the origin prediction first than start a 3-minute capture at the end of an iteration.

The prediction, so the next run is not exploratory

Under 1 unit per present, if the title's clock starts on its first drawn present, then the plate's a = 17 (first ramp step, t = 215) must land 215 presents after the title's first draw, and a = 255 at 236. Any consistent shortfall is the origin offset, in units, directly.

⚠️ And there is a second reading to keep open: the corpus's two 2026-08-29 runs measured settle → plate at 2.13 s with the title persisting long enough to show it, which these untapped runs do not. Whether the boot title and the post-movie title are the same screen with the same clock is not established, and the origin may differ between them.

The long capture was RUN, and it is still short — with the numbers to size the next one

Option 2 above was attempted this iteration: FRAMES=8000 MAXDRAWS=400000, 700 s.

frames captured        0 .. 5954
last movie luma frame  5954          <- still in the movie at the end
UI quads after it      0
draws logged           24 213  of a 400 000 cap

Neither cap fired. The run ended on the script's wall-clock timeout, not on frames or draws, so the fix is simply a longer window — nothing about the method is wrong.

Sizing it from what this run measured rather than from a guess:

presents consumed by the two splashes	~460
movie length ⟨disc⟩	137.714 s at 30.000 fps = 4 131 decoded frames
presents per decoded frame ⟨capture⟩	2
⇒ presents to the end of the movie	~8 260 + 460 ≈ 8 700
reached here	5 954 (~68 %)
achieved rate	~22 presents/s armed
⇒ armed seconds needed	~400 s, plus boot

So: FRAMES=9000, timeout ≥ 1200 s. 700 s was not enough and 8000 frames would have been.

📌 One saving available: the h= texture content hash reads guest memory on every sampled texture and the movie binds three planes per draw. The clock-origin measurement needs vertex alpha, not texture hashes, so a build without that field would run materially faster. The field is currently unconditional in tools/canary-patches/0004; putting it behind its own cvar is the obvious improvement and is not done.

Reach

⟨capture⟩ ×3, one machine, English locale, NOTAP=1, 600 presents. The negative is specific: within the first ~460 presents of boot, the title does not draw. It says nothing about what happens after the attract movie, which is precisely where the answer is.