From 1df492208bd543935d7f45773a60ae01cbb11097 Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sun, 30 Aug 2026 13:37:59 +0000 Subject: [PATCH] port: their withdrawn 14-unit hold does not touch my authored 9 -- it supports it Two warnings. The first does not reach me: nothing is authored from screen-transitions.md's 0.87/0.97/4.08 s spans, and nothing in this port reads keyframe times outside the crate -- their stale fade_quads.py failure mode cannot occur here by construction. The second is about black_hold_units: 9. Testing their structural claim on my export: pteff00 on main_menu is [0:a255 12:a0 70:a0 80:a255], rising to black over 70->80, while content fade-outs start at 58-60. That is 12 units of lead, exactly six frames at 30 Hz, matching their measurement off the running game -- disc and capture agreeing by independent routes. They say the two overlap; mine has a 2-unit gap, one frame, inside their stated resolution. The arithmetic: quad ramp 10 units + my authored 9 = 19 units = 0.317 s against their measured blackout of 18 units = 0.30 s. One unit apart, inside their own resolution. The measurement that withdrew the 14 supports my 9. It survived because I declined to author the 14 when the arithmetic was available and fit -- I wrote that it was arithmetic rather than a measurement and left the value where it had been measured. Had I adopted the composition I would now carry 24 units against a measured 18, which is the dead black they are warning about. Not adjusting 9; one transition, one run, +/-1 frame. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 62 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 61 insertions(+), 1 deletion(-) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index f69b48f6..7a3b6d76 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -9,7 +9,7 @@ dies, which is what this file is for. -159 sections. Search this before re-deriving anything. +160 sections. Search this before re-deriving anything. * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28) * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28) @@ -170,6 +170,7 @@ dies, which is what this file is for. * [Checking my own tree for the ordinal foot-gun that just voided three of theirs](#checking-my-own-tree-for-the-ordinal-foot-gun-that-just-voided-three-of-theirs) * [Looking for a case that separates width from mid-ramp — there is none, and I nearly invented one](#looking-for-a-case-that-separates-width-from-mid-ramp--there-is-none-and-i-nearly-invented-one) * [Auditing my tree for the disc-wide ordinal foot-gun](#auditing-my-tree-for-the-disc-wide-ordinal-foot-gun) +* [Their withdrawn "~14 units of black hold" — my authored 9 survives it](#their-withdrawn-14-units-of-black-hold--my-authored-9-survives-it) ## P0 — the exporter, 2026-08-28 @@ -9232,3 +9233,62 @@ exact and `a=127` holds flat across 134 units with position and scale constant. and a 200 % scale, and nobody has put that in front of the running game. The correction to my mid-ramp test stands on the numbers alone and needs no reading of what the element depicts — which is how it should have been written. + +## Their withdrawn "~14 units of black hold" — my authored 9 survives it + +Two warnings arrived. The first does not touch me: ✅ nothing of mine is authored +from `screen-transitions.md`'s 0.87 / 0.97 / 4.08 s fade-in spans, and **nothing +in this port reads keyframe times outside the crate** — the exporter reads them +through `sylpheed_formats`, and every analysis script I have reads +`export/*.json` downstream of it. Their `fade_quads.py` failure mode cannot occur +here by construction, which is the wall doing its job rather than luck. + +The second is about a value I ship: `authored/timing.json` `black_hold_units: 9`. +They withdrew the "~14 units of hold" and warn that **authoring a hold puts a +sixth of a second of dead black into every transition the game does not have**. + +### Testing their structural claim on my own export + +*"Content elements start fading about six frames before the black quad's ramp +begins."* On `main_menu`, `pteff00` is `[0:a255 12:a0 70:a0 80:a255]` — its rise +to black runs **t=70 → 80**. The content fade-outs start at: + +| element | starts | ends | +|---|---|---| +| `ptmsg` | **58** | 64 | +| `pteff10`, `pteff12` | 60 | 68 | +| `ptbtn05` | 60 | 64 | + +✅ **12 units of lead — exactly six frames at 30 Hz**, matching their measurement +off the running game. Two independent routes, disc and capture, same number. + +⚠️ One difference: they say the two **overlap**; in my export content is gone by +t=68 and the quad starts at t=70 — a 2-unit gap, not an overlap. That is one frame, +inside their stated ±1 frame per span, so I record it as agreement at their +resolution rather than as a discrepancy either of us can act on. + +### The arithmetic, which is the part that matters + +Their new figure: **total blackout 9 frames ≈ 0.30 s = 18 units**, gap between +screens one frame. + +| | units | +|---|---| +| quad's ramp to black, from the file | 70 → 80 = **10** | +| my authored `black_hold_units` | **9** | +| total from ramp start to the next screen | **19** = 0.317 s | +| their measured blackout | **18** = 0.30 s | + +✅ **One unit apart — inside their own resolution.** My authored 9 is *supported* +by the measurement that withdrew the 14, not refuted by it. + +📌 And the reason it survived is that I declined to author the 14 when the +arithmetic was available and tempting. The ramp+hold decomposition I proposed gave +20–24 units and fit their old ~0.4 s at the top of the range; I wrote *"this is +arithmetic that fits, not a measurement"* and left the value where it had been +measured. **Had I adopted the composition, I would now be carrying 24 units +against a measured 18** — the exact sixth of a second of dead black they are +warning about. + +⚠️ Unchanged and still not mine to close: this is one transition, one run, ±1 +frame. I am not adjusting 9, and there is nothing here that would justify it.