5d72bda77d
The time-based-clock claim rests on two captures that happened to run at different speeds. Nobody has changed the frame rate on purpose and watched. --framerate_limit=30 halves Xenia's vblank ceiling. Predictions committed before the run: quantity frame-based time-based (my claim) presents/s ~27 ~27 modal alpha step 17, unchanged 34, DOUBLED units/s ~30, halved ~60, unchanged splash dwells ~8.5 / ~7.0 s ~4.2 / ~3.5 s, unchanged Accept time-based only if the step lands in 30-38 AND the dwell stays within 10% of 4.2/3.5 s. If the step stays 17 and the dwell doubles, the claim is refuted, the clock is frame-based, and the port's 60 is unsupported again. The control is the present rate itself, read FIRST: a doubled step also appears if the limiter did nothing, so if presents/s does not fall to ~27 neither prediction is tested. Second control: the eight splash quad rects must be unchanged, or something other than the frame rate differs between runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2.8 KiB
Pre-registration — force the frame rate, and see which quantity moves
Committed BEFORE the capture. 2026-09-01. The designed falsification of
units-per-frame-is-not-a-constant.md,
which currently rests on two captures that happened to run at different speeds
rather than on one made to.
The claim under test
The UI clock advances by elapsed time, not by frame count.
units/presentis an artefact of the presentation rate;units/second ≈ 60is the invariant.
Evidence so far, all opportunistic:
| capture | presents/s | modal Δα | ⇒ units/present | ⇒ units/s |
|---|---|---|---|---|
h3 |
27.2 | 34 | 2.0 | 54.4 |
| boot 1 | 51.4 | 17 | 1.0 | 51.4 |
| boot 2 | 54.8 | 17 | 1.0 | 61.3 / 60.3 (from dwell) |
Two of the three ran at nearly the same rate. Nobody has yet changed the frame rate on purpose and watched.
The experiment
--framerate_limit=30. Xenia's limiter (graphics_system.cc) then marks vblank
at 30 Hz instead of 60, halving the ceiling on presents.
🔴 The predictions, stated now
| quantity | frame-based clock | time-based clock (my claim) |
|---|---|---|
| presents/s | ~27 | ~27 |
| modal Δα per present | 17, unchanged | 34, doubled |
| units/s | ~30, halved | ~60, unchanged |
| publisher splash dwell | ~8.5 s, doubled | ~4.2 s, unchanged |
| developer splash dwell | ~7.0 s | ~3.5 s, unchanged |
These diverge on every row but the first. I accept the time-based reading only
if the modal step lands in 30–38 and the dwell stays within 10 % of 4.2 /
3.5 s. If the step stays at 17 and the dwell doubles, my claim is refuted and
units/s is 30 at this limit, which would mean the clock is frame-based after
all and the whole rate question reopens with the port's 60 unsupported again.
⚠️ Note which way the risk runs: a doubled step is the result that confirms me, and it is also what a frame-based clock would show if the limiter did not actually take effect. So the control is the present rate itself — if presents/s does not fall to ~27, the flag did nothing and neither prediction is tested. That is the first number I will read, before the step.
Second control
The splash quad geometry must be unchanged — same eight NDC rects. If the rects move, something other than the frame rate changed between runs and the comparison is not clean.
What this cannot settle
Whether the console's rate is 60. Everything here is measured under Canary's limiter; the claim being tested is only that the clock is time-driven and that its rate is ~60 units/s as this emulator runs it. A time-based clock is immune to dropped frames, which is why that is worth something — but it is not the console.