Files
Sylpheed/docs/re/data/forced-framerate-test.txt
sylph-decoder 705a8485dc 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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2026-09-01 19:39:30 +00:00

27 lines
1.4 KiB
Plaintext

# --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