re: PRE-REGISTER the forced-frame-rate test of the time-based clock
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
This commit is contained in:
66
docs/re/time-based-clock-preregistration.md
Normal file
66
docs/re/time-based-clock-preregistration.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# 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`](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/present`
|
||||
> is an artefact of the presentation rate; **`units/second ≈ 60` is 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.
|
||||
Reference in New Issue
Block a user