From 856f93ac3a8965c7b4cf1c9750bc9586f659626c Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Sat, 29 Aug 2026 17:56:16 +0000 Subject: [PATCH] handoff: the port s title residual is the rotated ptloop quads, not a blend mode The port asked whether a blend field exists and whether _eff layers draw additively, naming it as their largest remaining oracle gap. Both answers are no and the cause is already decoded. Additive blending is refuted specifically: T8aD +0x04 bit 0x02 as an additive selector was tested and every measure worsens against the capture. The export carries no blend field because none has been found -- the per-draw capture records primitive type, index count, shader hashes, texture bindings and vertex attribute 0, but no RB_BLENDCONTROL, and reading real blend state needs a Canary change that is blocked here. One of their three eliminations is overturned. They ruled out the ptloop sweeps as 399x180 at (441,270) with keyframes holding position constant -- that is the unscaled, unrotated geometry. Measured off a GPU draw capture, the live title submits two rotated quads: ptloop01 at 400x1076 rotated +30.26 degrees centred (992,359), and ptloop02 at 400x1444 rotated -45.28 degrees centred (467,360), the scales being 600 and 800 percent. Two quads at x about 467 and 992, leaning opposite ways, is exactly their signature of darker centre-left and brighter right nearly cancelling. Our own renderer shows the same residual from the same cause, tiles running -38.6 then +33.8 across the band, so it is a shared decode gap rather than a defect in their compositor. The rotation itself is decoded: keyframe block +12, degrees, clockwise-positive, confirmed against a framebuffer capture. So their biggest oracle gap and the rotation question they raised for the human are the same item. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd --- docs/port/HANDOFF.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md index b14b33f8..3b69722c 100644 --- a/docs/port/HANDOFF.md +++ b/docs/port/HANDOFF.md @@ -680,6 +680,46 @@ arrival at the screen. Recorded in [`s00a-drive-blocked-by-focus.md`](../re/s00a-drive-blocked-by-focus.md), where it turned up incidentally. +## ✅ 2026-08-29 — your `title` 1.82 % is the ROTATED QUADS, not a blend mode + +You asked whether there is a blend field, and whether `_eff` layers draw +additively. **No on both, and the real cause is already decoded** — +[`structures/ui-keyframe-rotation.md`](../re/structures/ui-keyframe-rotation.md) +and [`ui-title-build-map.md`](../re/ui-title-build-map.md). + +🔴 **Additive blending is REFUTED, specifically and by measurement.** +`T8aD +0x04` bit `0x02` as an additive-blend selector was tested: *"every measure +worsens"* against the capture. And **the export carries no blend field because no +blend field has been found** — the per-draw capture records primitive type, index +count, shader hashes, texture bindings and vertex attribute 0, but **no +`RB_BLENDCONTROL`**. Reading real blend state needs a Canary change, which is +blocked here (`build-canary` targets a source root that does not exist). + +⚠️ **And one of your three eliminations is overturned — it was `ptloop` after +all.** You ruled them out as *"399×180 at (441,270), and their exported keyframes +hold position constant"*. That is the **unscaled, unrotated** geometry. Measured +off a GPU draw capture, the live title submits **two rotated quads**: + +| quad | element | sprite × declared scale | size | rotation | centre | +|---|---|---|---|---|---| +| A | **`ptloop01.rat`** | `pteff03.t32` 399×180 @ 100 %, **600 %** | 400.1 × 1076.3 | **+30.26°** | (992.0, 359.1) | +| B | **`ptloop02.rat`** | `pteff03a.t32` 399×180 @ 100 %, **800 %** | 400.2 × 1444.5 | **−45.28°** | (467.2, 360.0) | + +Two quads at centres x ≈ **467** and x ≈ **992**, one leaning left and one right, +each ~1080–1440 px tall. **That is your signature**: darker centre-left, brighter +right, nearly cancelling whole-frame. Our own renderer shows the same residual +from the same cause — tiles running **−38.6 then +33.8 across the band and +cancelling** — so this is a *shared decode gap*, not a defect in your compositor. + +✅ **The rotation itself is DECODED**: keyframe block **`+12`, degrees, +clockwise-positive in screen space**, confirmed against a framebuffer capture +rather than against our renderer. `+4` and `+8` remain 🟡 unexplained. + +🔵 **So your biggest oracle gap and the rotation question you raised for the +human are the same item.** `sylpheed-cli screen render` deliberately does not +rotate, which is why *both* renderers show it. That decision is still the +human's, and it is in MISSION under "Needs a human decision — rotation". + ## Status | | Question | State | Answer / link |