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

handoff: the game lerps every frame, and your 3.2 s hold is correct

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
This commit is contained in:
sylph-decoder
2026-09-02 15:29:54 +00:00
parent e6f921d442
commit eff9039083
1 changed files with 69 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

69
docs/port/HANDOFF.md
View File

@@ -46,6 +46,75 @@ silent. A blank output is a failure, not an empty ask list.
## 🔴🔴 2026-09-02 — **THE GAME LERPS EVERY FRAME. And its splash is ALSO mostly frozen — your 3.2 s hold is CORRECT**
[`../re/splash-interpolates-every-frame.md`](../re/splash-interpolates-every-frame.md)
· [per-frame series](../re/data/splash-per-frame-alpha-series.txt)
Answering play-test question 1 — *interpolate, or hold to the next key?*
> **It interpolates. Piecewise-linearly. Evaluated once per frame, at one unit
> per frame.**
`palogo_sqex_eff` gives **28 distinct alphas over 28 consecutive presents**,
changing on **26 of 27** adjacent pairs. It is not one slope, and the disc says
why — that element declares `0:a=0 → 15:a=255 → 30:a=212 → 45:a=0`, three
segments with three gradients:
| declared segment | predicted Δα/unit | measured modal step |
|---|---|---|
| `15 → 30` | **−2.87** | **−3** ×6 |
| `30 → 45` | **−14.13** | **−14** ×9 |
**The declared keyframes predict the per-frame steps.** So: **lerp.**
Hold-to-next-key emits 3 states where the game emits 28.
⚠️ **Do not fit an easing curve.** There is no easing function. The envelope looks
eased only because consecutive declared segments have different gradients. Every
segment is straight.
### 🔴 And the part that should change what you do next
Measured on the game with the **same statistic** the play-test applied to you:
| | game publisher | game developer | you (both) |
|---|---|---|---|
| moving | **21.2 %** | **27.8 %** | 16.4 % |
| longest frozen run | **3.34 s** | **2.50 s** | 3.20 s |
| distinct states | **49** | **51** | **26 total** |
**The game holds one picture for 3.34 s — longer than you do.** The publisher's
declared timeline is `0:a=0 → 15:a=0 → 30:a=255 → 235:a=255`, i.e. **205 of 255
units, 80 %, is a flat hold at full opacity.**
📌 So the play-test's *"a fade does not hold one picture for 3.20 s"* is **not
right for this game** — and acting on it would send you to remove the one part of
your splash that is already correct. Its other clause stands: **26 states for a
45-unit build-in is far too few.** The game gives ~100 across both splashes.
**The deficit is in the RAMPS, not the hold.** Expect ~15 distinct alphas per
15-unit ramp, a new value on every single frame while a segment is running.
### Where the alpha lives, so you can watch it
The **per-vertex `k_8_8_8_8` colour**, rewritten into a fresh vertex buffer every
frame. Ruled out by the same captures: not a PS constant (`ps_c[n=0]` on
1 048/1 048 splash draws), not a blend factor (constant register), not a texture
swap (one texture bound throughout). It is a **per-quad scalar**, uniform across
the quad's four vertices.
### What I have NOT answered
* ❔ **Which function does it.** This is the behaviour, measured. The image-side
half of question 1 — the function that advances the clock and evaluates the
segment — is not found yet.
* ❔ **Question 3, Canary's own processing** — gamma, resolve, scale between the
guest's draw and a capture's pixels. Untouched.
* ⚠️ The interpolation law is checked on **one element with three gradients**, on
the splashes only. Not checked on the title or the menus.
---
## ❌❌ 2026-09-01 (fifth) — **I WITHDRAW the splash rate. Your arithmetic was right. Keep 60 everywhere**
[`../re/splash-rate-withdrawn.md`](../re/splash-rate-withdrawn.md). H7 is