705a8485dc
Ran --framerate_limit=30 against predictions committed beforehand. Every
discriminating row went to the frame-based column:
frame-based time-based (mine) measured
presents/s ~27 ~27 28.4
modal alpha step 17 unchanged 34 doubled 17 UNCHANGED
units/s ~30 halved ~60 unchanged 30.2 / 30.3
publisher dwell ~8.5 s ~4.2 s 8.450 s DOUBLED
developer dwell ~7.0 s ~3.5 s 6.923 s DOUBLED
Both controls passed first. The limiter took effect (28.4 presents/host-s
against 51-55, interval mass moving from one 60 Hz vblank to two, 422 of
468), and all 8/8 splash quad rects are identical so nothing but the frame
rate differs.
So the UI clock advances exactly 1 unit per presented frame. The step is 17
on every quad at 28.4, 51.4 and 54.8 presents/s, and 255*1/15 = 17 with the
declared T=15. units/second = presents/second, and seconds are not a
property of the game.
The port's 60 stands: the guest presents once per 60 Hz vblank
unconstrained, and 1 unit per present at 60/s is 60 units/s. Same answer as
my first position, finally with a tested mechanism instead of an inference.
This withdraws units-per-frame-is-not-a-constant.md in its central claim.
My "a time-based clock is immune to dropped frames so the dwell is stable"
was a real prediction and it failed -- the dwell doubled. The four-run
agreement I read as evidence was four runs at similar frame rates.
h3-units-per-frame-measured.md's +34 is now the anomaly rather than the
rule: 34 per label at 27.2 labels/s against 17 per present at 28.4
presents/s. Both cannot be presents. Not asserting it is wrong, only that
one of them must explain the disagreement.
Three of my four positions came from inference over a measured quantity;
this one came from changing an input and watching what moved. The
opportunistic comparison pointed exactly the wrong way because nothing
controlled what else differed between those captures.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
92 lines
4.6 KiB
Markdown
92 lines
4.6 KiB
Markdown
# ✅ The UI clock is FRAME-based: **1 unit per present**, verified by a forced frame rate
|
||
|
||
**Status: ✅ measured, by a designed test that REFUTED my own previous claim.**
|
||
2026-09-01. Instrument: ⟨capture⟩ ×3, one of them at a deliberately altered
|
||
presentation rate. Answered against
|
||
[`time-based-clock-preregistration.md`](time-based-clock-preregistration.md),
|
||
committed before the run.
|
||
Data: [`data/forced-framerate-test.txt`](data/forced-framerate-test.txt).
|
||
|
||
---
|
||
|
||
## The test, and it went against me
|
||
|
||
I claimed the clock was **time**-based and that `units/second ≈ 60` was the
|
||
invariant. I predicted that halving the frame rate would **double** the alpha step
|
||
and **leave** the dwell unchanged. I ran `--framerate_limit=30`:
|
||
|
||
| | frame-based | **time-based (my claim)** | **measured** |
|
||
|---|---|---|---|
|
||
| presents/s | ~27 | ~27 | **28.4** |
|
||
| modal Δα per present | 17 unchanged | 34 doubled | **17 — unchanged** |
|
||
| units/s | ~30 halved | ~60 unchanged | **30.2 / 30.3 — halved** |
|
||
| publisher dwell | ~8.5 s | ~4.2 s | **8.450 s — doubled** |
|
||
| developer dwell | ~7.0 s | ~3.5 s | **6.923 s — doubled** |
|
||
|
||
**Every discriminating row went to the frame-based column. My claim is refuted.**
|
||
|
||
Both controls passed first, as pre-registered:
|
||
|
||
* **Control 1, read before the step:** the limiter took effect — 28.4 presents per
|
||
host-second against 51–55 before, and the interval histogram's mass moved from
|
||
**one** 60 Hz vblank to **two** (422 of 468). Had this failed, neither
|
||
prediction would have been tested.
|
||
* **Control 2:** all **8/8** splash quad rects identical to the reference set, so
|
||
nothing but the frame rate differs between runs.
|
||
|
||
## What is actually true
|
||
|
||
> **The UI clock advances exactly 1 unit per presented frame.** The step is
|
||
> **17** on every quad in every capture — at 28.4, 51.4 and 54.8 presents per
|
||
> second. `255 × 1 / 15 = 17` with the declared `T = 15`.
|
||
|
||
So `units/second = presents/second`, and the *seconds* are whatever the frame
|
||
rate makes them. The dwell in seconds is **not** a property of the game.
|
||
|
||
## The conclusion for the port is unchanged, and now properly grounded
|
||
|
||
The guest, unconstrained, presents **once per 60 Hz vblank** — measured before the
|
||
limiter was applied (one vblank 71.7 %, two 24.6 %), and confirmed by this run
|
||
moving cleanly to two vblanks when told to. One unit per present at 60 presents
|
||
per second is **60 units/s**.
|
||
|
||
**The port's 60 is right.** It was right when I first said so for a bad reason,
|
||
right when I withdrew it, right when I replaced it with 120, and right now — the
|
||
difference is that the mechanism is finally tested rather than inferred.
|
||
|
||
## 🔴 What this withdraws, including of my own
|
||
|
||
* **`units-per-frame-is-not-a-constant.md` is WRONG in its central claim** and is
|
||
superseded by this page. Units per frame *is* a constant; it is 1.
|
||
* **My "dwell is stable across runs because a time-based clock is immune to
|
||
dropped frames"** was a real prediction and it **failed** — the dwell doubled.
|
||
The four-run agreement at 4.2 / 3.5 s that I read as evidence for a time-based
|
||
clock was just four runs at similar frame rates.
|
||
* ⚠️ **`h3-units-per-frame-measured.md`'s `+34` is now the anomaly**, not the rule.
|
||
It reports 34 per label at 27.2 labels/s; this capture reports 17 per present at
|
||
28.4 presents/s. **Both cannot be presents.** The likeliest reading is that an
|
||
`h3` label is not one present, and until that is checked its "2 units per frame"
|
||
should not be used. I have not checked it, and I am not asserting it is wrong —
|
||
only that it and this disagree at nearly the same rate, which one of them must
|
||
explain.
|
||
|
||
## The methodological point, since this is the fourth reversal today
|
||
|
||
Three of my four positions on this number came from **inference over a measured
|
||
quantity**; this one came from **changing an input and watching what moved**. The
|
||
opportunistic comparison — two captures that happened to differ — pointed exactly
|
||
the wrong way, because I had no control on what else differed between them. The
|
||
designed test cost one capture and settled it against my own expectation.
|
||
|
||
📌 And the pre-registration did its job in the only way that really counts: it
|
||
made the refuting result **unmissable**. Had I not written down "34, doubled"
|
||
first, "17" would have been easy to read as confirmation of something.
|
||
|
||
## Reach
|
||
|
||
⟨capture⟩ ×3 at two deliberately different rates, one machine, English locale.
|
||
The invariance of the step is the load-bearing part and now rests on a
|
||
manipulation rather than a coincidence. ❔ Whether the console presents at 60 is
|
||
still an inference from the vblank cadence — a short one, since a 360 vblanks at
|
||
60 Hz, but an inference.
|