fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

handoff: the port s title residual is the rotated ptloop quads, not a blend mode

Browse Source 
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) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
This commit is contained in:
sylph-decoder
2026-08-29 17:56:16 +00:00
parent 3bd1a61ea9
commit 5a4428ec67
1 changed files with 40 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
docs/port/HANDOFF.md
View File

@@ -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 |