re: verify the splash's opaque-black backdrop, and the noun amendment

sylpheed-port found the fifth member of our error family on their own side: their
"visible" test counted any element with alpha > 0, which includes palogo_eff0.
Verified from the disc rather than accepted --

  entry 10  [0] palogo_eff0.prm  1 kf  t=0  fade=0xff000000  scale=100x100  pos=(0,0)
  entry 11  same

Alpha 255 over RGB 000000: full-screen opaque black, drawn from t=0 and showing
nothing. So "any element drawn" reports these screens visible from t=0 while the
frame is black -- "visible" read as "drawn".

Worth having on its own: this verifies from the disc the premise behind
`screen render --black`, which its own help states as "what the game composites
over on a screen carrying its own background". On the splash builds that
background is DECLARED, not assumed.

METHOD gains their amendment, which is the sharpest formulation either of us
reached this week: all five instances are a failure of a NOUN, not of a number.
Extent, bounding box, duration, span, visible. The number was always correct FOR
SOMETHING; what went missing was which thing. Every other check in that file
tests whether a number is right, and not one tests whether it is a number of the
thing you think.

Also teaches fade_quads.py to address a PAK ENTRY directly (`e10`) rather than
only a build ordinal. The splashes are entries 10/11 and are not screen builds,
so no ordinal addresses them -- and writing `e10` states which index space is
meant, which is the standing lesson of build-ordinal-vs-entry.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 17:30:37 +00:00
parent d13cefd664
commit 18f3c5d3dd
3 changed files with 44 additions and 4 deletions

View File

@@ -424,6 +424,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
window shorter than the effect — a mismatch between what you are looking at and
what you believe you are looking at.
📌 **And the amendment that explains why this class survives everything else in
this file** (`sylpheed-port`'s, and it is the sharpest formulation either agent
reached): **all of them are a failure of a NOUN, not of a number.** Extent,
bounding box, duration, span, *visible*. In every case the number was correct
**for something** — what went missing was *which thing*. Every other check here
tests whether a number is **right**; not one tests whether it is a number **of
the thing you think**. A fifth instance landed the same day: counting "any
element with alpha > 0" as *visible*, when the splash builds declare
`palogo_eff0.prm` at `0xff000000` — full-screen **opaque black**, drawn from t=0
and showing nothing. Drawn is not visible.
## Runtime / emulator
* **Look at the PNG** — and check its dimensions.

View File

@@ -125,6 +125,27 @@ to correct in, and nothing here supports moving `keyframe_units_per_second`.
in all three boots (1.011, 1.083, 1.028) while the developer sits at unity. Three
boots per screen is thin and it is not a systematic.
### ✅ And the splash builds carry their own OPAQUE BLACK backdrop — verified
`sylpheed-port` found the fifth family member on their own side while confirming
the above: their "visible" test counted **any element with alpha > 0**, which
includes `palogo_eff0.prm`. Checked against the disc
(`tools/re-capture/fade_quads.py e10 e11`):
```
entry 10 [0] palogo_eff0.prm 1 kf t=0 fade=0xff000000 (alpha 255) scale=100x100 pos=(0,0)
entry 11 [0] palogo_eff0.prm 1 kf t=0 fade=0xff000000 (alpha 255) scale=100x100 pos=(0,0)
```
Alpha 255 over RGB `000000`: **full-screen opaque black, drawn from t=0 and
showing nothing.** So "any element drawn" reports these screens visible from t=0
while the frame is black — **"visible" read as "drawn"**, the fifth member.
📌 **Worth having on its own:** this verifies, from the disc, the premise behind
`screen render --black` — *"what the game composites over on a screen carrying its
own background, and so what a framebuffer capture must be compared against"*. On
the splash builds that background is **declared**, not assumed.
📌 **This is the fourth instance of one family** — pivot anchor read as drawn
extent, centre track as bounding box, cycle length as motion duration, and now
**one element's visible span read as the screen's**. Every one is a number used as

View File

@@ -52,10 +52,18 @@ E = pak_entries(pak)
E = [b for h,b in E]
# build index -> pak entry index, from `screen list`: 0..9 then 12, 15
BUILDS = {0:0,1:1,2:2,3:3,4:4,5:5,6:6,7:7,8:8,9:9,10:12,11:15}
want = [int(a) for a in sys.argv[1:]] or [2,4,5,6]
for b in want:
names, groups = parse(E[BUILDS[b]])
print(f"=== build {b} ===")
# An argument may be a BUILD ordinal (mapped through BUILDS) or, prefixed with
# `e`, a raw PAK ENTRY -- the splashes are entries 10/11 and are NOT screen
# builds, so no build ordinal addresses them. Writing `e10` says which index
# space is meant, which is the whole lesson of build-ordinal-vs-entry.md.
want = sys.argv[1:] or ["2","4","5","6"]
for arg in want:
if str(arg).startswith("e"):
idx = int(str(arg)[1:]); label = f"entry {idx}"
else:
idx = BUILDS[int(arg)]; label = f"build {arg} (entry {idx})"
names, groups = parse(E[idx])
print(f"=== {label} ===")
for i,nm in enumerate(names):
if not nm.endswith(".prm"): continue
g = groups.get(i, [])