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.