The Decoder proposes a per-screen rate: ~57 units/s for the title, ~35-40 for the splashes, on the ground that a splash at 60 runs 1.5-1.7x too fast. That would be a timeline cause for the human's finding 4, so it matters. THE PORT DID NOT MOVE, and this is why. The 160-unit hold is identifiable: exactly one interval in either splash is 160 units, the DEVELOPER splash's a=255 plateau at t=30..190, inside its declared group t=0..210. So: the 160-unit hold measured 4.514 guest s (1 run) -> 35.4 units/s the 210-unit group AROUND IT measured 3.37/3.50/3.51 s (3 cold boots) -> 60.7 A sub-interval cannot outlast the interval containing it. That is not two methods disagreeing about a rate, it is arithmetic, and one of the two is wrong. Both dwell measurements corroborate ~60 on exactly the two screens now put at 35-39: publisher 255 units in 4.30/4.60/4.37 = 57.7, developer 210 units in 3.37/3.50/3.51 = 60.7, the developer agreeing with its declared value to 1.1 % and two of its runs to 0.3 %. At 35.4 the declared groups would run 5.93 s and 7.20 s -- each splash ~70 % longer than three cold boots measured it. The one escape route is named rather than dismissed: the new figure is in GUEST seconds and the corpus in wall-clock. The known gap between those is Canary at ~28.1 fps against 30, which is 6 % and the wrong direction to close 1.7x. It is their instrument and their clock, so it is asked (H7), not ruled out. ⚠️ The STRUCTURAL claim may still be right -- one rate covering every screen is what is under challenge, and the title's 56.8 does sit ~5 % off the splashes' 58-61. If a per-screen rate is real the port wants the MECHANISM, a field or a GamePart constant, not two authored numbers. That is their next item. Recorded in authored/timing.json so the next iteration does not quietly adopt it, with an explicit instruction not to split the difference: averaging two measurements that cannot both be true is not a third measurement. Also this iteration: H6 -- answered in principle, blocked in practice. They are right that the blend is a decoded disc field (T8aD +0x04 bit 0x02) and that deriving beats transcribing, which would delete an authored entry. But sylpheed-formats does not EXPOSE +0x04 -- Element surfaces kind (+40), parent (+32), pivot, keyframes, focus_link -- and sylpheed-export consumes formats by git TAG, not workspace path, so I cannot reach the parser. Asked: surface the word and tag it. 🔴 And a negative worth having, since it is the obvious thing to try: kind_raw in this export is NOT that field. Its bit 0x2 against the additive map over four screens is ANTI-correlated -- 0 of 14 mapped elements have it set and 9 unmapped ones do. Anyone reaching for `kind_raw & 2` gets the additive set exactly inverted. H5 -- closed. My shared-element hypothesis is refuted: build_12 and build_15 have identical declaration bodies, so identical statistics are one fact. The pgloading_loop5 localisation stands and is the better answer. ✅ And the good news, recorded where the splash work lives: "the declared keyframe timeline reproduces the captured splash" settles in favour of the timeline -- 50 captured alphas, worst error one level in 255, no renderer in the chain. The port's splash keyframes were never the defect. Which leaves the RATE as the remaining candidate for what the human saw, and the rate is what this commit declines to change. Not settled: which of the two splash measurements survives; where a per-screen rate would come from; the +0x04 exposure; H1 (key repeat). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
270 lines
16 KiB
JSON
270 lines
16 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.",
|
|
"",
|
|
"🔴 2026-09-01 — THE FIRST LEG ABOVE IS RETIRED. THE VALUE IS NOT.",
|
|
"",
|
|
"'2 units per rendered frame ... a 30 Hz game, giving 60 units per second' is a",
|
|
"FRAME-COUNT derivation, and the Decoder retired that mechanism the same day",
|
|
"(docs/re/units-per-second-measured.md): the same animation takes 21 frame",
|
|
"labels in one capture and 33 in another, and one splash logo steps +136,+34 in",
|
|
"one run and +17,+51,+34,+34,+17,+17 in the other. A fixed per-frame increment",
|
|
"cannot do that. The clock is TIME-INTEGRATED, not frame-counted, so `units =",
|
|
"2 x frames` computes an emulator artefact. The 2 was that run's frame pacing.",
|
|
"",
|
|
"✅ The port's RUNTIME was already right: `boot.gd` advances",
|
|
"`time_units += delta * units_per_second`, off delta time. Nothing in this port",
|
|
"derives a unit from a frame count. Audited 2026-09-01, and it is why the",
|
|
"retirement cost a justification and not a behaviour.",
|
|
"",
|
|
"✅ AND THE SECOND LEG NEVER TOUCHED A FRAME COUNT, which is why 60 survives:",
|
|
"the transition quad is declared black for 12 units and the capture bracketed",
|
|
"the pure-black plateau at 0.14-0.30 s (title-plate-delay-measured.md, at a",
|
|
"0.125 s sampling resolution). 12 units in 0.14-0.30 s is 40-86 units/s. That",
|
|
"is a declared unit count against a wall-clock duration, with no frames in the",
|
|
"chain -- and it EXCLUDES 120 units/s, which would need 0.10 s.",
|
|
"",
|
|
"✅ MEASURED DIRECTLY 2026-09-01: 56.8 units per guest second, control passing",
|
|
"at 1.15 %, from two elements agreeing at one clock (`ptbtn00` 657.9 alpha/s,",
|
|
"`ptcopyright` 650.4 alpha/s, which puts ptcopyright's segment at T = 22.25 --",
|
|
"a rate agreement AND a round declared length). 30 and 120 are both excluded.",
|
|
"",
|
|
"60 IS KEPT. 56.8 is 5.6 % away against a ~5 % quantisation resolution, so it",
|
|
"does not refute 60, and the Decoder explicitly did not ask for a change. The",
|
|
"reach is the TITLE: the splashes are a different GamePart and nothing yet shows",
|
|
"they tick at the same rate.",
|
|
"",
|
|
"⚠️ If anyone re-fits this from alpha: DROP THE LAST STEP of a ramp. It clamps",
|
|
"at 255 and reports more elapsed time than it consumed -- worth 4 % on the plate.",
|
|
"",
|
|
"🔴 2026-09-01 (later) — A PER-SCREEN RATE WAS PROPOSED AND NOT ADOPTED.",
|
|
"",
|
|
"docs/re/splash-declared-vs-captured.md proposes ~57 units/s for the title and",
|
|
"~35-40 for the splashes, i.e. that one constant cannot be right and that a",
|
|
"splash at 60 runs 1.5-1.7x too fast. THE PORT DID NOT MOVE, and the reason is",
|
|
"arithmetic on a measurement already cited in this file:",
|
|
"",
|
|
" the 160-unit hold is the DEVELOPER splash's a=255 plateau, t=30..190, and it",
|
|
" is measured at 4.514 s. The 210-unit group CONTAINING it is measured at",
|
|
" 3.37/3.50/3.51 s over three cold boots (the dwell_why block below). A",
|
|
" sub-interval cannot outlast the interval containing it.",
|
|
"",
|
|
"The same three boots put the splashes at 57.7 and 60.7 units/s -- corroborating",
|
|
"60 on exactly the two screens the new figure puts at 35-39. At 35.4 the declared",
|
|
"groups would run 5.93 s and 7.20 s against corpus dwells of 3.37-3.51 and",
|
|
"4.30-4.60, i.e. each splash ~70 % longer than measured.",
|
|
"",
|
|
"⚠️ DO NOT ADOPT EITHER NUMBER UNTIL THAT IS RESOLVED, and do not split the",
|
|
"difference -- averaging two measurements that cannot both be true is not a",
|
|
"third measurement. docs/port/splash-rate-contradiction.md, asked as BLOCKED H7.",
|
|
"",
|
|
"⚠️ AND THE STRUCTURAL CLAIM MAY STILL BE RIGHT. 'One rate cannot cover every",
|
|
"screen' is a claim about the format, and the title's 56.8 does sit ~5 % off the",
|
|
"splashes' 58-61. If a per-screen rate is real this file should carry a MECHANISM",
|
|
"-- a field or a GamePart constant -- not two authored numbers. The Decoder has",
|
|
"'where the per-GamePart rate comes from' as its next item."
|
|
],
|
|
"kind": "measured",
|
|
"source": "/reborn docs/port/HANDOFF.md Q1, docs/re/ui-keyframe-time-unit.md, docs/re/units-per-second-measured.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."
|
|
],
|
|
"ramp_kind": "measured",
|
|
"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 [refuted] 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."
|
|
],
|
|
"dwell_kind": "measured",
|
|
"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 = NOT MODELLED. The escalation is resolved: a uniform value is positively",
|
|
"EXCLUDED, so 0 is no longer one option among several -- it is the only honest",
|
|
"uniform choice, because it is the one that does not claim a constant exists.",
|
|
"",
|
|
"UPDATE: TWO candidate models are now excluded, not one. The Decoder has five",
|
|
"replicates with NO variation -- title->menu 3,3,3 and EXTRAS->menu 2,2 -- and",
|
|
"every differing value comes from a different ORDERED PAIR. The same origin",
|
|
"gives different values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3).",
|
|
"So a constant is excluded AND keying on the outgoing screen is excluded; only",
|
|
"an ordered-pair key survives, with a measured value needed per pair.",
|
|
"",
|
|
"I checked independently whether anything DECLARED predicts it, from the",
|
|
"quantities in my export. None does: outgoing close (15,10,10,10), incoming",
|
|
"clear (12,12,16,12), outgoing span (269,74,80,80) and incoming span",
|
|
"(80,80,269,74) each have two rows sharing a value with different gaps.",
|
|
"",
|
|
"I did NOT search combinations of them. Four intra-archive pairs against many",
|
|
"candidate two-screen functions fits by construction -- that is the error this",
|
|
"corpus has catalogued five times, and finding a formula here would be",
|
|
"indistinguishable from finding one in noise.",
|
|
"",
|
|
"The Decoder ordered the gaps by the screen being LEFT (frames): menu 0 and 1,",
|
|
"EXTRAS 2, title 3. Three hypotheses are positively ruled out, not merely",
|
|
"unsupported. DIRECTION: EXTRAS->menu (2) and menu->EXTRAS (1) are the same",
|
|
"pair both ways and differ. BUTTON: (B) gives 0 and 2, (A) gives 1 and 3.",
|
|
"INCOMING SCREEN: an incoming menu takes 3 from the title and 2 from EXTRAS.",
|
|
"",
|
|
"So the quantity varies 0-3 frames by outgoing screen, and any uniform non-zero",
|
|
"value is wrong as a MODEL rather than merely off in magnitude. 0 models the",
|
|
"gap as absent; 6 would model it as constant, which the data excludes.",
|
|
"",
|
|
"MY OWN RULE IS REFUTED, not just unadopted. It was gap + the incoming",
|
|
"screen's opening black-clear = a constant, holding at 16/16/18 on three",
|
|
"transitions. Their fourth gives 16, 14, 16, 18 -- and decisively, the two",
|
|
"transitions with the SAME incoming screen (main_menu) have different gaps,",
|
|
"so the incoming screen cannot determine it. A fourth point did to a",
|
|
"three-point fit exactly what it should.",
|
|
"",
|
|
"DO NOT key this per outgoing screen yet. Three outgoing screens with one",
|
|
"value each restates the data rather than predicting it -- the same objection",
|
|
"I raised against my own 16/16/18. Key it when a screen has more than one",
|
|
"measured value, and key it on the screen being LEFT.",
|
|
"",
|
|
"📌 CITATION ADDED 2026-09-01, and its absence propagated from the delivery.",
|
|
"This why carried over a thousand characters and NOTHING OPENABLE. The Decoder",
|
|
"sent the `(B)`-from-EXTRAS leg as an inline frame table with no file cited,",
|
|
"while docs/re/data/fade-four-transitions.txt -- which carries that leg and",
|
|
"eight others -- had been committed the whole time. They found it in their own",
|
|
"audit and cited it; it had already landed here uncited.",
|
|
"",
|
|
"⚠️ An uncited measurement propagates as an uncited value. The receiving end",
|
|
"cannot tell a summarised measurement from a recalled one, and both read as",
|
|
"prose.",
|
|
"",
|
|
"✅ AUDITED 2026-09-01 and this one needed nothing: it was already an EXCLUSION argument rather than a count. It excludes a constant, excludes keying on the outgoing screen, and excludes every declared quantity in the export as a predictor -- four of them named, each shown not to separate the pairs. That is the form the week's other claims were found to be missing."
|
|
],
|
|
"black_hold_kind": "measured"
|
|
}
|