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

port: confirm the plate quad by size, and record a frame-spacing discrepancy I cannot close

Browse Source 
Read the Decoder's existing title draw log from the ref. The additive quad carries
per-vertex alpha 68, 67, 56 across log frames 1, 2 and 4.

Identification confirmed independently and without using their attribution: the
quad is 537.6 x 75.6 px and ptbtn00f.png ships at 537 x 76.

Their free check on my ramp holds -- all three alphas are at or below my declared
peak of 80 and none equals a keyframe value, so the game interpolates rather than
steps. Two independent decodes agreeing.

The frame spacing does not fit. At HANDOFF Q1's 2 units per rendered frame my
falling segment predicts 68, 64.5, 57.6 against observed 68, 67, 56; at 0.5 units
it predicts 68, 67.2, 65.4. No constant rate fits both steps.

Three candidates I cannot separate: my ramp is wrong somewhere, the log's frame
numbering is captured rather than engine frames -- it skips from 2 to 4, so it is
demonstrably not dense -- or emulator pacing varies. The middle is most likely and
cheapest to check, and it is theirs.

It does not disturb the ramp's shape or ceiling, which the alphas confirm. It
disturbs only posing my renderer at their captured instant by stepping units, so
the vertex alpha stays the right readout and a frame index would have been wrong.
This commit is contained in:
Sylpheed port agent
2026-08-31 11:56:29 +00:00
parent dfb768270a
commit 3e9160b372
1 changed files with 41 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
docs/port/DECISIONS.md
View File

@@ -16515,3 +16515,44 @@ number could not settle this even at peak α.
⚠️ Their gate `wait_plate_pulse.py` fires on a green-glyph count in [500, 2500] and
has logged 740 and 1004, so the window may come free or may sit outside [35, 50]
entirely. Their caveat, carried across rather than assumed away.
### The plate identification is confirmed by size; the frame spacing does NOT fit my ramp
Reading the Decoder's existing title draw log from the ref
(`captures/ui-draws/blend-title-2026-08-31.log`), the additive quad they point at
is draw 8/19/…, `blend=0x01010101`, per-vertex `col=44FFFFFF` / `43FFFFFF` /
`38FFFFFF` — α **68, 67, 56**.
✅ **Identification confirmed independently, by size.** The quad measures
**537.6 × 75.6** px and `ptbtn00f.png` ships at **537 × 76**. That is the plate's
highlight, and it settles it without using their attribution.
✅ **And their free check on my ramp holds:** all three alphas are ≤ my declared
peak of **80**, none equals a keyframe value, so the game interpolates rather than
steps. Two independent decodes agreeing — mine from the export, theirs from the
command stream.
🔴 **But the frame-to-frame spacing does not fit, and I am recording that rather
than passing over it.** `HANDOFF` Q1 gives **2 units per rendered frame**. On my
falling segment (slope −1.744 α/unit) that predicts, from α=68:
| | frame 1 | frame 2 | frame 4 |
|---|---|---|---|
| observed | 68 | **67** | **56** |
| my ramp at 2 units/frame | 68 | 64.5 | 57.6 |
| at 1 unit/frame | 68 | 66.3 | 62.8 |
| at 0.5 | 68 | 67.2 | 65.4 |
**No constant rate fits both steps** — 0.5 matches frame 2 and misses frame 4 by
9; 2 matches frame 4 and misses frame 2 by 2.5.
⚠️ **Three candidates and I cannot separate them:** my ramp is wrong somewhere; the
log's frame numbering is *captured* frames rather than engine frames (**it skips
from 2 to 4**, so it is demonstrably not a dense engine sequence); or emulator
pacing varies between them. The middle one is the most likely and the cheapest to
check, and it is theirs.
📌 This does **not** disturb the ramp's *shape* or *ceiling*, which the alphas
confirm. It disturbs only the claim that I could pose my renderer at their captured
instant by stepping units — so the vertex alpha remains the right readout, and
**inferring the phase from a frame index would have been wrong.**