33f141a3df
The port raised this as load-bearing and it is answered, without a speed factor. I expected to find the three cold boots slow and argue contamination. They are not. My capture reproduces them: publisher 4.263 s against 4.297 / 4.604 / 4.370, developer 3.457 s against 3.508 / 3.503 / 3.366. Four runs agree, so that defence is unavailable and I am not using it. The flaw is in the comparison. 2.125 s is the publisher's declared ANIMATION length; 4.3 s is how long the SCREEN is up, and the screen holds after the timeline ends. Measured as counts in one capture: the publisher is on screen for 219 presents and animates for about 128 of them. The falsifier would have found a contradiction at any units-per-second. The decisive number needs no speed factor: 51.4 presents per host-second on the publisher splash, 53.8 on the developer. Xenia's limiter marks vblank at 60 Hz and caps presents there. A 30 fps guest presents every second vblank, at most 30 per second, and a slow emulator can only make intervals longer. 51.4 > 30, so a 30 fps guest cannot produce this. A 60 fps guest can: 51.4 is 86% of 60, matching the vblank histogram's 14% drops. So 60 units/s is refuted by a count against a hard limit rather than by a duration against a fitted factor -- the argument the 2.13 s reconciliation could not make. The dwell corpus stands in its own terms. Those seconds are the screen's dwell on this emulator, reproducible, and were never a statement about units per second. Recording what I got wrong on the way: I first segmented the atlas eras as "both splashes then the title" and briefly had a 2x discrepancy that would have let me declare the dwell corpus contaminated. The segmentation was wrong, and the durations matching the corpus to 1% is what exposed it. A convenient answer from an unchecked segmentation is the same trap as a clean answer from an unguarded assumption. Reach unchanged: still one boot for the hash ratio. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
17 lines
914 B
Plaintext
17 lines
914 B
Plaintext
# The splash dwell, measured as a COUNT of presents and separately as a
|
|
# host-clock duration, in ONE capture. Same run, same game, both numbers.
|
|
|
|
segment 0: presents 1..219 n= 219 host= 4.263s 51.4 presents/host-s -> 102.7 units/host-s
|
|
segment 1: presents 224..409 n= 186 host= 3.457s 53.8 presents/host-s -> 107.6 units/host-s
|
|
|
|
# The corpus's three COLD BOOTS of the same two splashes, wall clock:
|
|
# publisher 4.297 / 4.604 / 4.370 s developer 3.508 / 3.503 / 3.366 s
|
|
# (boot-order-and-splash-dwell.md)
|
|
# THIS run, both splashes end to end: 409 presents in 7.831 s
|
|
|
|
# A 30 fps guest presents at most 30 times per second of guest time, and
|
|
# Xenia's vsync limiter caps presents at 60/s. Any measured rate ABOVE 30
|
|
# per host-second is therefore impossible for a vblank-paced 30 fps guest
|
|
# unless the emulator runs the guest faster than real time, which a
|
|
# 60 Hz-limited emulator cannot do.
|