They answered ask #2 -- the gap is deterministic, not a load -- and held me to re-stating the choice against four measurements (0, 6, 4, 6) rather than the three it was made on. That is my own standard for check-all's stale allowance turned around. The arithmetic moved against 0: it costs 2.0x the best fit on four measurements against 1.7x on three, and is now the minority outcome, wrong on 3 of 4 where a uniform 6 is wrong on 2 of 4. Still 0, because the reason was never the fit -- it adds no black the game does not have, and is measured-correct for a real transition rather than for an average of them. Picking 6 because it appears twice is choosing a mode from four samples when their finding is that a rule exists and nobody has found it. But one leg is gone and is not being kept quietly: part of the case for 0 was that the quantity might be machine-dependent and unauthorable. It is not. That removes an excuse without supplying a value. Added a tripwire: if the gap is non-zero in most transitions and no rule emerges, omitting a real quantity stops being caution and becomes a different invention. The port is wrong by 4-6 units on three of four known transitions and the why now says so. Also records as settled: the outgoing ramp is the declared final ramp, my {8,10,10} against their measured multiset, two independent routes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF
183 lines
10 KiB
JSON
183 lines
10 KiB
JSON
{
|
|
"format": "sylpheed.timing/1",
|
|
"keyframe_units_per_second": 60,
|
|
"why": [
|
|
"HANDOFF Q1. The disc says a keyframe is at `t=30`; it does not say what a",
|
|
"`t` is. The unit was MEASURED off the running game, not decoded: a declared",
|
|
"15-unit fade lands on round(255*k/15) for all seven of its samples with k",
|
|
"stepping 2,4,6,8,10,12,14 on seven consecutive submitted frames -- so 2",
|
|
"units per rendered frame -- and the idle title presents at 28.3-28.8 fps,",
|
|
"a 30 Hz game, giving 60 units per second. A second line agrees: the",
|
|
"transition quad is declared black for 12 units, and a capture measured the",
|
|
"pure-black plateau at 0.17-0.23 s, where 12/60 = 0.20 s.",
|
|
"",
|
|
"Expressed as units-per-second rather than seconds-per-unit so the value is",
|
|
"exact rather than a repeating decimal a reader has to recognise.",
|
|
"",
|
|
"DELETE THIS FILE when a field on the disc is found that states the unit.",
|
|
"Nothing here is on the disc.",
|
|
"",
|
|
"🔴 DO NOT 'CORRECT' THIS AGAINST AN EMULATOR FRAME RATE. A draw-stream",
|
|
"measurement on 2026-08-29 found the presented units-per-frame rising 33 % over",
|
|
"a single boot (1.765 early, 2.357 late) and three independent readings of one",
|
|
"container's rate disagreeing with each other. That is the EMULATOR's",
|
|
"presentation pacing drifting, and no single units-per-frame figure describes a",
|
|
"run there.",
|
|
"",
|
|
"60 is a different quantity: the GAME's logical unit rate, measured off the",
|
|
"running game as HANDOFF Q1 (a declared t=30 landing on the linear value at",
|
|
"every one of seven sampled frames). The port renders at its own frame rate and",
|
|
"converts through this constant, so guest pacing cannot reach it. The two",
|
|
"numbers are not comparable and one is not evidence about the other."
|
|
],
|
|
"kind": "measured",
|
|
"source": "/reborn docs/port/HANDOFF.md Q1, docs/re/ui-keyframe-time-unit.md",
|
|
"ramp": "linear",
|
|
"ramp_why": [
|
|
"Also HANDOFF Q1, and part of the same measurement: the fade lands on the",
|
|
"linear value at every one of the seven sampled frames, so there is no ease."
|
|
],
|
|
"dwell_seconds": null,
|
|
"dwell_why": [
|
|
"NOT SET -- because the dwell is DECLARED, and the port already plays it.",
|
|
"",
|
|
"This key has now been wrong in two opposite directions, and the second was",
|
|
"mine, so both are recorded.",
|
|
"",
|
|
"It first said 'a screen's dwell is its OWN keyframe group'. Then GP_TITLE",
|
|
"build 4 was measured dwelling ~1100 presented frames against a declared ~120,",
|
|
"and I generalised that into 'the boot is KNOWN TOO FAST on both splashes'.",
|
|
"🔴 THAT WAS AN OVER-CORRECTION and it is withdrawn. Build 4 is the title: its",
|
|
"exit is caused by something outside its timeline, so it holds. A splash's exit",
|
|
"is caused by nothing, so it plays its declared timeline and leaves. The title",
|
|
"is the exception, not the rule, and one screen was never enough to overturn",
|
|
"the other two.",
|
|
"",
|
|
"MEASURED 2026-08-29 by the Decoder over 3 cold boots",
|
|
"(docs/re/structures/boot-splash-dwells-are-declared.md):",
|
|
"",
|
|
" publisher declared t=0..255 = 4.250 s corpus 4.30 / 4.60 / 4.37",
|
|
" developer declared t=0..210 = 3.500 s corpus 3.51 / 3.50 / 3.37",
|
|
"",
|
|
"The developer agrees to 1.1 %, two of its three runs to 0.3 %. The port emits",
|
|
"4.400 s and 3.650 s -- each declared value plus the 9-unit black hold, exactly.",
|
|
"So the pacing was right all along and nothing changes in the code.",
|
|
"",
|
|
"🔴 AND THE UNIT STAYS UNITS, NOT SECONDS. The same two dwells timed in the",
|
|
"Decoder's own container came out 15-20 % LONGER than both the declared values",
|
|
"and the corpus -- same disc, same timeline -- and three independent readings",
|
|
"of that container's rate disagree with each other. A seconds figure records",
|
|
"one emulator's pacing on one run. The units are on the disc. If anything ever",
|
|
"goes in `dwell` it is an extra hold in UNITS, and only for a screen that is",
|
|
"measured to wait beyond its group."
|
|
],
|
|
"looping_focus_records": {
|
|
"_": [
|
|
"WHICH focus records the port draws, unconditionally and on a loop, OVER the",
|
|
"element's own sprite rather than instead of it.",
|
|
"",
|
|
"RESTORED 2026-08-30 on a MEASUREMENT, having been deleted on 2026-08-29 for",
|
|
"a real defect that was in the RENDERER, not in this table. The old entry made",
|
|
"`_draw` substitute the glow for the plate's own bright sprite, so the plate",
|
|
"was invisible at every instant (max 0 against max 252.5). `ScreenView` now",
|
|
"draws the base and the record over it, and the entry comes back."
|
|
],
|
|
"press_start/ptbtn00": {
|
|
"record_element": "ptbtn00f",
|
|
"period_units": 120,
|
|
"kind": "measured",
|
|
"source": "docs/re/structures/plate-pulse-measured.md, RE agent 2026-08-30",
|
|
"why": [
|
|
"MEASURED off the running game, held at the title with NO INPUT: the plate",
|
|
"oscillates continuously -- two windows in one boot of 58 s and 57 s, about",
|
|
"23 cycles each, with no decay and no settling.",
|
|
"",
|
|
"🔴 IT NEVER GOES OFF. The plate-absent floor is 159 thresholded green",
|
|
"pixels -- the title art's own, measured on live-title-build4-no-plate.png --",
|
|
"and the pulse bottoms at 714, four and a half times that. So `ptbtn00`",
|
|
"going transparent at t=244 is not the end of the plate; that is its EXIT",
|
|
"ramp, which plays when the screen leaves. While the screen is held the base",
|
|
"sits at its own hold (alpha 255 at t=238) and `ptbtn00f`'s cycle runs over",
|
|
"it. Base-only and base-plus-glow are what the 714 and the 1520 are.",
|
|
"",
|
|
"⚠️ 120 UNITS, NOT SECONDS, and that is the RE agent's own instruction. Their",
|
|
"run measured 2.530 and 2.540 s; an earlier corpus run measured 2.24 s. Same",
|
|
"declared number, different emulator pacing -- x1.27 and x1.12 against a",
|
|
"nominal 2.000 s, which IS 120 units at 60 units/s. Hardcoding 2.5 s would",
|
|
"author one loaded container's clock."
|
|
],
|
|
"limits": [
|
|
"ONE BOOT. Two windows inside it are not two boots.",
|
|
"It does NOT distinguish the boot title from an attract-loop title: run 1",
|
|
"opens at t~255 s against Q9's ~193 s no-input baseline, so it may already",
|
|
"be the attract title. Both are 'the title, held, no input' -- which is what",
|
|
"was asked -- but it is not proof about the first appearance.",
|
|
"🔴 714/1520 IS NOT AN ALPHA RATIO. The counter is thresholded pixels, so dim",
|
|
"pixels drop out first. No duty cycle and no ramp shape may be read off it;",
|
|
"the port draws the record's own declared alpha ramp and infers nothing."
|
|
]
|
|
}
|
|
},
|
|
"exit_ramp_deleted_why": [
|
|
"DELETED 2026-08-29, and the deletion is the point.",
|
|
"",
|
|
"`exit_ramp_seconds` (~0.4 s) and `exit_ramp_units` (24) were AUTHORED because",
|
|
"the disc had no time slot on a group's final keyframe, so the ramp into it was",
|
|
"the one unknown duration per screen. Under the corrected record layout",
|
|
"(formats-pin-2026-08-29c onward) there IS no untimed keyframe -- a group is an",
|
|
"8-byte header then frames x {u32 time; 36-byte pose}, so every pose is timed",
|
|
"including the last. The unknown the constant stood in for does not exist.",
|
|
"",
|
|
"MISSION section 3: 'When the RE agent later decodes something you had",
|
|
"authored, delete the authored entry and let the exporter emit it. That",
|
|
"deletion is the measure of progress.'",
|
|
"",
|
|
"VERIFIED DEAD BEFORE DELETING, not assumed: setting it to 9999 (166 seconds)",
|
|
"changed the boot's transitions by 0.04 s -- wall-clock jitter, not a 166 s",
|
|
"ramp. Both of its uses in ScreenView were gated on `not last_frame.has('t')`,",
|
|
"which no longer fires on any of the export's 866 keyframes.",
|
|
"",
|
|
"The measurement it recorded is not lost: HANDOFF Q7's ~0.4 s fade-out and the",
|
|
"0.17-0.23 s black hold are still measured facts, and the hold is still used --",
|
|
"`tools/port/verify-dwell` compares a transition INTERVAL against the oracle's",
|
|
"visible SPAN plus that hold. What is deleted is the port's need to invent a",
|
|
"duration the disc now states."
|
|
],
|
|
"black_hold_units": 0,
|
|
"black_hold_why": [
|
|
"0, RE-DERIVED against FOUR measurements, not inherited from three.",
|
|
"",
|
|
"The Decoder's measured black gaps are now 0, 6, 4, 6 units across four",
|
|
"transitions. When this was set to 0 the multiset was (0, 4, 6), and they held",
|
|
"me to re-stating the choice against the new data rather than carrying it --",
|
|
"the same standard I applied to check-all's stale allowance.",
|
|
"",
|
|
"The arithmetic moved AGAINST 0 and it is worth writing down rather than",
|
|
"burying: a uniform 6 is wrong on 2 of 4 transitions for a total error of 8;",
|
|
"0 is wrong on 3 of 4 for a total of 16. Choosing 0 cost 1.7x the best fit on",
|
|
"three measurements and costs 2.0x on four. 0 is now the MINORITY outcome --",
|
|
"three of four transitions do have a gap.",
|
|
"",
|
|
"IT IS STILL 0, and the reason is unchanged because it was never the fit: 0",
|
|
"adds no black the game does not have, which is the tie-breaker",
|
|
"input_during_transition already uses in this file, and it is measured-correct",
|
|
"for a real transition rather than for an average of them. Picking 6 because",
|
|
"it appears twice is choosing a mode from four samples with no rule behind it.",
|
|
"",
|
|
"ALSO CHANGED: the gap is NOT machine-dependent. It was defensible to hold 0",
|
|
"partly because the quantity might be a load and therefore unauthorable; the",
|
|
"Decoder has now shown it is deterministic to the frame -- bundle size runs the",
|
|
"wrong way, and a repeat run moved press-to-first-change by ~12 frames while",
|
|
"the gap did not move at all. So this is a real game quantity with a rule",
|
|
"nobody has found, not noise. That REMOVES an excuse for 0 without supplying a",
|
|
"value.",
|
|
"",
|
|
"TRIPWIRE, because 'invent nothing' can stop being conservative: if the gap is",
|
|
"non-zero in most transitions and no rule emerges, systematically omitting a",
|
|
"real quantity is no longer the cautious choice -- it is a different invention.",
|
|
"Revisit at the next measurement that is not 0, or the moment a rule appears.",
|
|
"The port is currently wrong by 4-6 units on three of four known transitions",
|
|
"and says so here rather than in a number that looks decided."
|
|
]
|
|
}
|