From 9e73990d1bc26c85f7374949b90f392b2e0ce093 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 19:39:30 +0000 Subject: [PATCH] re: the clock is FRAME-based, 1 unit per present -- my own test refuted my claim 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 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- ...ock-is-frame-based-one-unit-per-present.md | 91 +++++++++++++++++++ docs/re/data/forced-framerate-test.txt | 26 ++++++ 2 files changed, 117 insertions(+) create mode 100644 docs/re/clock-is-frame-based-one-unit-per-present.md create mode 100644 docs/re/data/forced-framerate-test.txt diff --git a/docs/re/clock-is-frame-based-one-unit-per-present.md b/docs/re/clock-is-frame-based-one-unit-per-present.md new file mode 100644 index 00000000..464abe7f --- /dev/null +++ b/docs/re/clock-is-frame-based-one-unit-per-present.md @@ -0,0 +1,91 @@ +# ✅ 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. diff --git a/docs/re/data/forced-framerate-test.txt b/docs/re/data/forced-framerate-test.txt new file mode 100644 index 00000000..79b54479 --- /dev/null +++ b/docs/re/data/forced-framerate-test.txt @@ -0,0 +1,26 @@ +# --framerate_limit=30. Pre-registered in time-based-clock-preregistration.md. +# CONTROL 1: 28.4 presents/host-s (was 51-55). Limiter took effect. + +CONTROL 2 -- the eight splash quad rects must be unchanged: + quads found 8; matching the reference set: 8/8 -> PASS + +THE DISCRIMINATOR -- modal alpha step per present: + pre-registered frame-based: 17 unchanged | time-based: 34 doubled + x[-0.52,0.52] y[-0.1,0.08] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153] + steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17 + x[-0.39,0.39] y[0.35,0.55] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153] + steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17 + x[-0.19,0.19] y[-0.12,0.12] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153] + steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17 + x[-0.3,0.3] y[-0.62,-0.25] alphas [17, 34, 51, 68, 85, 102, 119, 136, 153] + steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17 + x[-0.41,0.41] y[0.32,0.57] alphas [68, 85, 102, 119, 136, 153, 170, 187, 204] + steps [17, 17, 17, 17, 17, 17, 17, 17] modal=17 + +UNITS PER SECOND -- pre-registered frame-based ~30 | time-based ~60: + splash 0: 244 presents, 8.450s host -> 255u/8.450s = 30.2 units/s + (boot1 4.263s, boot2 4.162s at ~52 presents/s) + splash 1: 204 presents, 6.923s host -> 210u/6.923s = 30.3 units/s + (boot1 3.457s, boot2 3.485s at ~52 presents/s) + +VERDICT: FRAME-BASED -- my claim is REFUTED