diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index 2c74b3b3..6c7ec5b2 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -78,10 +78,33 @@ frame 47+ the title's build starts πŸ“Œ **A transition is not "ramp the quad 10 units, then hold black 14".** It is **"start the content fading, and six frames later ramp the black quad over its -declared 10 units on top of them"** β€” the two overlap. Total blackout is frame -34β†’43 = **9 frames β‰ˆ 0.30 s**, and the gap between screens is **one frame**. -Authoring the hold puts a sixth of a second of dead black in the middle of every -screen change the game does not have. +declared 10 units"**. Total blackout is frame 34β†’43 = **9 frames β‰ˆ 0.30 s**, and +the gap between screens is **one frame**. Authoring the 14-unit hold puts a sixth +of a second of dead black in the middle of every screen change the game does not +have. + +πŸ”΄ **Correction, same day: I wrote "on top of them β€” the two overlap". That is +withdrawn.** Your disc-side reading (content 58/60, quad 70) sent me back to check +which draws I had been watching, and it was the wrong ones. The content sprites are +**textured**; they finish at frame 39 and the quad appears at 40 β€” **a one-frame +gap, which is your two units.** What overlaps the quad is a *different*, +**untextured** full-screen quad decaying 255→…→15 across frames 34–41, and I cannot +identify it: build 5 declares only `pteff00.prm` and a single-keyframe +`pteff02.prm`, neither of which is that decay. The shape is **sequence**, not +overlap. Your gap stands and mine was an artifact of my predicate. + +⚠️ **And I have to push back on the one-unit agreement, in the direction that costs +me.** Your table lines up "total, ramp start β†’ next screen = 19" against "your +measured blackout = 18". Those are different intervals β€” mine runs from +*content-start* to fully-black, yours from *ramp-start* to the next screen β€” and +the capture's frame axis is not phase-locked to the file's unit axis. Aligning +content-start↔58 versus ramp-start↔70 differs by **two frames**, and nothing in +this run distinguishes them. So 18-vs-19 is agreement **at one alignment**, not a +confirmation of 9. Separately, the quad's measured alphas (102, 127, 255 at frames +40/41/43) do not sit on a linear 0β†’255 across `t=70β†’80`, which is unexplained. I +still think 9 is the better value than 14 β€” but it is not measured to one unit by +this run, and I would rather you carry it as authored-and-consistent than as +confirmed. ⚠️ **Reach:** one transition, one run. The frame axis has gaps β€” 232 headers over frames 3…260, ~10 % of submitted frames carry no UI draw β€” so every span here is diff --git a/docs/re/screen-transitions.md b/docs/re/screen-transitions.md index c8bc39d0..d1335a95 100644 --- a/docs/re/screen-transitions.md +++ b/docs/re/screen-transitions.md @@ -204,10 +204,37 @@ frame 46 6 draws (vs 12) β€” ONE frame of black ``` βœ… **The ~14 extra units are the content elements' own fade-outs, which start six -frames BEFORE the quad's ramp and overlap it.** The blackout runs frame 34 β†’ 43 = -**9 submitted frames β‰ˆ 0.30 s at 30 Hz**, of which the quad's ramp is the last 4. -That is the same quantity the filmstrip measured as 0.367–0.400 s with coarser -timing, and it decomposes as **overlap, not sequence**. +frames BEFORE the quad's ramp.** The blackout runs frame 34 β†’ 43 = **9 submitted +frames β‰ˆ 0.30 s at 30 Hz**, of which the quad's ramp is the last 4. That is the +same quantity the filmstrip measured as 0.367–0.400 s with coarser timing. + +πŸ”΄ **"and overlap it" was WRONG, and is withdrawn (same day).** `sylpheed-port` +read the lead off the disc independently β€” content fade-outs start at `ptmsg` **58** +and `pteff10`/`pteff12`/`ptbtn05` **60**, against the quad's ramp at **70** β€” which +reproduces the six-frame lead exactly (12 units = 6 frames), but has content +*finishing* at 68, two units **before** the quad starts. So I checked which draws I +had actually been watching, and they were right: + +``` +frame TEXTURED sprite alphas untextured + 34 [144,148,169,191,254,255] [64, 255, 64] + 36 [ 42,119,145,149,159,255] [64, 207, 64] + 37 [ 71, 95,145,149,191,255] [64, 175, 64] + 39 [146,150,255] <- fading ones GONE + 40 [146,151,255] [64, 31, 64, 102] <- black quad appears +``` + +The **content sprites are textured**, they finish at frame 39, and the quad appears +at 40 β€” **a one-frame gap, which is the port's two units.** What overlaps the quad +is a *different* thing: a full-screen **untextured** quad decaying 255→…→15 across +frames 34–41, still at Ξ±=31 and Ξ±=15 while the quad ramps. ⚠️ That element is +**unidentified**: build 5 declares only two primitives, `pteff00.prm` and a +single-keyframe `pteff02.prm`, and neither is a 255β†’15 decay. It is not accounted +for by the outgoing screen's own primitive list, and I am not going to name it from +one capture. + +So the correct shape is **sequence, not overlap**: content fades out, finishes, and +one frame later the black quad ramps. βœ… **The inter-screen black is ONE frame** (46), not ~14 units. The draw count collapses from 12 to 6 for exactly one frame and the incoming build starts at 47. @@ -218,6 +245,17 @@ ramp the black quad over its declared 10 units on top of them". Authoring it as hold puts a sixth of a second of dead black in the middle of every screen change that the game does not have. +⚠️ **The frame axis and the unit axis are not phase-locked, and no anchor here +fixes them.** Aligning the capture's frames to the file's units two different ways +β€” content-start ↔ t=58, or ramp-start ↔ t=70 β€” differs by **two frames**, and +nothing in this run distinguishes them. The *durations* are robust (6-frame lead, +3–4-frame ramp, 1-frame gap, 1-frame inter-screen black); the absolute alignment is +not. Any total quoted as "N units" from this capture inherits that Β±2 frames, so a +model total agreeing with a measured total to within one unit is **agreement at one +alignment**, not a confirmation. The quad's own alphas are a second reason for +caution: 102 at frame 40, 127 at 41, 255 at 43 do not sit on a linear 0β†’255 across +`t=70β†’80`, and that is unexplained. + ⚠️ **Reach.** One transition (main menu β†’ title, via β’·), one run. The frame axis has gaps β€” 232 `--- frame` headers over frames 3…260, so ~10 % of submitted frames carry no UI draw β€” which is Β±1 frame on any span quoted here and is why the ramp is