6aab30253a
The Port asked which of two of my measurements to believe, 55 units/s vs ~150, a factor of 2.7 off one game. Measured on the plate's own declared ramp, against a pre-registration committed first. PREDICTED 11 frames at 2 units/frame, 4.4 at the Port's inferred 5, +/-1. MEASURED 10 labels, and three consecutive gap-free steps of EXACTLY 23, which is 255*2/22 on the nose. 5 units/frame is excluded by >2x. Why the splash read as 5: an alpha step is not a clock rate. For a linear segment d(alpha)/frame = 255*(units/frame)/T. Splash B's quads step 34 with a declared T=15; the plate steps 23 with a declared T=22; ONE clock, two steps 1.5x apart. And the Port's intervals start at each quad's first submission, which on splash A is already alpha=85 -- not the element's t where alpha=0, and biased by a different amount per element because T differs. My own splash-quad-timeline.txt published alpha against frame with no T beside it, which is the column that makes the conversion possible; it now carries the warning. The other half: the 'title settled' anchor is ptcopyright reaching full alpha -- the last build-in element and the ONLY glyph one, which is what a glyph counter settling means. Calibrated on the plate's own ramp it lands at t~168 (t~176 at a flat 2.0/label). The Port's candidates are 118 and 160, 42 units apart: this is 8-16 units from 160 and 50-58 from 118. It is 160. Instrument fact that bounds all of it: labels with zero draws exist, ~1 in 5, and the clock does NOT advance a fixed amount across them -- across label 5376 the plate moved +82 where three adjacent labels each moved +23. So an empty label is a real advance, not a logger artefact, and spans that cross one are approximate. The conclusion rests on the gap-free steps. Also recorded: the sweep leaves never settle. They translate monotonically through every label examined and are still moving when the plate arrives, so 'settled' can only mean the build-in elements are done. NOT answered, and it is what the port actually needs: units per SECOND. units/s = (units/frame) x (guest fps); this pins the first at 2 and says nothing about the second, and 2x30 vs 2x60 differ by exactly the ~2 s the human reported. My own title-plate-delay-measured.md's 2.13 s does not reconcile with this capture's 20 labels for the same two anchors -- a real ~2.9x disagreement, now localised to frames->seconds rather than units->frames. Settling it needs the guest's own frame counter, which neither capture read.
1.9 KiB
1.9 KiB