From 2b646f5b1ed56c74769fb4c8c0c187fad5a1a1cb Mon Sep 17 00:00:00 2001 From: Sylpheed port agent Date: Sat, 29 Aug 2026 20:52:06 +0000 Subject: [PATCH] port: the loading screens are black at EVERY instant, which disproves my layer rule build_12 and build_15 have rendered blank since P3 and I had filed it as a rest() casualty. It is not, and the corrected keyframe association makes it provable. pgloading_eff00, a 1280x720 black quad, is opaque alpha 255 from t=0 to t=38 and clears at t=48. Every other element on the screen peaks between t=8 and t=32 and is gone by t=32-40. So the quad covers the entire span in which any content is up, and clears only after everything else has faded. Rendered with the timeline PLAYING at t = 20, 30, 36, 40, 42, 44, 46 and 50 units, the frame is mean 0 at every one. That is not a bad choice of pose. Under the port's current layer rule there is no instant at which this screen shows anything, and a loading screen that is black for its whole life is not what the game does -- a proof by contradiction rather than a preference. THE RULE UNDER SUSPICION IS MINE AND IT IS NARROW. pgloading_eff00 carries layer_source "none" and the exporter sorts a layerless element LAST, on top. Every other full-frame primitive in the export has a layer key (main_menu, extras and title all give pteff00 0x00008030), so this only ever bites here -- which is why it survived eight milestones behind two screens nobody draws. Where a layerless element sorts is a DECODE and I have not answered it. If the game sorts it first, behind everything, the screen renders and the quad becomes a backdrop, which is consistent with the contradiction but not established. Asked rather than flipped. It does settle that verify-screen's BLANK verdict on those rows was right: sylpheed-cli agrees with the port there precisely because it shares the assumption under suspicion. Also recorded: the Decoder has withdrawn "the game never draws eff3" -- it draws all five -- and the mechanism is the one my developer-splash refutation caught a layer down. A draw batches several quads and the log dumps only the first 8 vertices, so min/max merges them; eff3 lies entirely inside eff4 so the union is exactly eff4's extent. My 525x259 was gamearts_eff merged with seta_eff the same way. Nothing in the port changes: eff3 was never dropped and the splash still draws three sprites. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF --- docs/port/DECISIONS.md | 73 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 73 insertions(+) diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md index e1265347..136ae6bb 100644 --- a/docs/port/DECISIONS.md +++ b/docs/port/DECISIONS.md @@ -4821,3 +4821,76 @@ that number is the *denominator* of the units-per-frame conversion behind the 9-unit black hold I just authored, so an error in it would have propagated straight into a constant I ship. Two derivations from different sides of the same record agreeing to 0.02 % is what makes that constant safe to hold. + +## 🔴 The loading screens are black at *every* instant — which proves the layer rule wrong for a layerless element + +`build_12` and `build_15` have rendered blank since P3, and I had filed it as a +`rest()` casualty: `pgloading_eff00` is a 1280×720 quad whose `rest` is opaque +black. **It is not that**, and the corrected keyframe association makes it +provable rather than suspected. + +Every element's declared alpha window on `build_12`: + +| element | opaque / visible | gone by | +|---|---|---| +| **`pgloading_eff00`** (black quad) | **t=0 … 38 at alpha 255** | clears at t=48 | +| `pgloading_loop4` | t=8…32 | 38 | +| `pgloading_loop1` | t=16…32 | 40 | +| `pgloading_line` | t=18…26 | 32 | +| `pgloading_str` | t=22…28 | 34 | +| `pgloading_loop3` | t=24…26 | 34 | +| `baseeff`, `eff01`, `eff02`, `loop5` | t≈16…32 | 32–40 | + +**The quad is fully opaque across the entire span in which any content is up, and +it only clears at t=48 — by which time every other element has faded to zero.** +Rendered at t = 20, 30, 36, 40, 42, 44, 46, 50 units with the timeline *playing*, +the frame is **mean 0 at every one**. + +So this is not a bad choice of pose. **Under the port's current layer rule there +is no instant at which this screen shows anything**, and a loading screen that is +black for its whole life is not what the game does. That is a proof by +contradiction, not a preference. + +### The rule under suspicion is mine, and it is narrow + +`pgloading_eff00` carries `layer_source: "none"` — no layer key at all — and the +exporter sorts a layerless element **last**, i.e. on top. Its `paint_order` is +`[6, 7, 8, 9, 1, 5, 4, 2, 3, 0]` with element 0, the quad, drawn last. + +⚠️ **Every other full-frame primitive in the export has a layer key** — +`main_menu`, `extras` and `title` all give their `pteff00` `0x00008030` — so this +rule only ever bites here, which is exactly why it survived eight milestones +behind two screens nobody draws. + +❔ **Where a layerless element sorts is a decoding question and I am not +answering it.** If the game sorts it *first* — behind everything — the screen +renders and the quad becomes a backdrop rather than a cover, which is what a +1280×720 black rectangle at the bottom of a loading screen would sensibly be. +That reading is *consistent* with the contradiction above, which is not the same +as being established, and I have asked rather than flipped the sort. + +✅ **What this does settle:** `verify-screen`'s `BLANK` verdict on those two rows +was the right call. It reports that both renderers drew nothing and that the row +proves nothing — and `sylpheed-cli` agrees with the port here precisely because +it shares the assumption under suspicion. Two renderers agreeing, again. + +## Their `eff3` retraction — my refusal was right, and my refutation found the same bug + +The Decoder has withdrawn *"the game never draws `eff3`"*. It draws all five, in +the declared stagger, in both title entries. **And the mechanism was the one my +developer-splash refutation had already caught one layer down**: a draw batches +several quads and the log dumps only the first 8 vertices, so min/max over a +line's vertex list *merges* them. `eff3` (788…1196) lies entirely inside `eff4` +(447…1196), so the union is exactly `eff4`'s extent and `eff3` vanished with +nothing anomalous to see. My `525×259` was `gamearts_eff` merged with `seta_eff` +by the identical mechanism. + +⚠️ **The part worth carrying is theirs**: three explanations were reported "ruled +out", and all three were aimed at the wrong failure — the *"a draw the log cannot +see"* check counted draws with **no** geometry when the hiding place was draws +with **partial** geometry. **Refuting three wrong hypotheses is not evidence for +a fourth**, and a list of failure modes written by whoever built the instrument +is the least likely to contain that instrument's blind spot. + +Nothing in the port changes: `eff3` was never dropped, and the developer splash +still draws three sprites.