ee3be08750
sylpheed-port named the mechanism after copying an unchecked aside of mine into an authored file twice, inside the same why that carefully said their re-derivation does not name the screen. Scrutiny goes where the weight is, so a claim carrying no weight attracts none, and then it reads as measured. Swept this corpus for the shape and found one in the port's own domain. ui-composable-bundles.md said a .prm element 'has no sprite and is skipped as everywhere else'. True of our compositor, false of the game: the element is palogo_eff0.prm, which ui-forced-backdrop.md decodes as the full-screen opaque black backdrop, forced first, measured off the running game. The page's load-bearing draw order was pinned by a disc test and checked; the aside was not. The generalising phrase is the tell -- 'as everywhere else' is what turns a statement about our tooling into one about the disc. Also records that a refutation is exactly as wide as the job a claim was offered for: 37 of the 63 pairs differ without a button-count mismatch, where my reading is unsupported rather than refuted, and they wrote the bound when the wider version was available. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
4.7 KiB
A screen build is not the only thing compose can draw
Status: ✅ CONFIRMED by measurement over the disc, with the artifact to
show for it. 🟡 the wider set is not "all screens" — most of what it adds are
fragments. ❔ what distinguishes a screen from a fragment in the file is unknown.
The gap
ui_layout::is_build — the predicate every screen command and every disc test
enumerates with — requires a .rat layout child:
ratc::is_ratc(bundle) && kids.iter().any(|c| c.name.ends_with(".rat"))
The developer-logo splash has none. Its elements name their T8aD sprites
directly (palogo_gamearts.t32), so there is nothing for a .rat record to
place, and parse_build handles it perfectly well — it was simply never reached.
That was worse than a missing screen. The splash is one of only two screens
whose paint order has been read off the running game
(ui-paint-order-key.md), and it is the one where the
layer key explains the whole permutation. Its measurement could not be checked
against a render, because there was no way to produce one.
The measurement
| count | |
|---|---|
| RATC bundles on the disc | 2 859 |
pass is_build |
965 |
pass is_composable (declaration table + a resolvable T8aD) |
2 751 |
passing is_build but not is_composable |
0 |
So the new predicate is a strict superset, not a rival rule.
But the 1 786 extra bundles are not 1 786 screens. They are dominated by two-element fragments — a button beside its glow:
GP_READY_ROOM.pak +792 GP_MAIN_GAME_*2D.pak +108 each (six languages)
GP_DEBRIEFING_PILOTLOG.pak +164 GP_HANGAR_ARSENAL.pak +96
e.g. 2 els: ["pvbtnnew.t32", "pvbtnneweff.t32"]
2 els: ["py_menu_new.t32", "py_menu_new_eff.t32"]
That is why is_build stays the default. Widening it would also renumber
--build for every pak, and the corpus's notes cite build indices by number
(GP_TITLE build 4, entries 11/14, GP_OPTIONS build 11) — silently shifting
them would invalidate written-down evidence.
What landed
ui_layout::is_composable, and an opt-in --all on screen list, screen info
and screen render. Default behaviour and default numbering are unchanged.
$ sylpheed-cli screen render dat/GP_TITLE.pak splash.png --all --build 11 --black
build [11]: drew 6/7 elements
not drawn (1): ["palogo_eff0.prm"]
All three logos with their glows behind them. The seventh element is a .prm
primitive, which has no sprite and is skipped by this composite — 🔴 "skipped
as everywhere else", corrected 2026-08-31. That phrasing was true of our
compositor and false of the game: the element is palogo_eff0.prm, and
ui-forced-backdrop.md decodes it as the full-screen
opaque black backdrop, forced FIRST — opaque at 211 instants, below 6 of 6, and
that order is measured off the running game. It does not skip; it paints, and it
paints under everything.
⚠️ Why this line and not the ones around it. The load-bearing claim on this page — the draw order
[2,4,6,1,3,5], pinned by a disc test and matching the oracle — got the scrutiny. The aside did not, because it carried no weight.sylpheed-portnamed the mechanism after importing an unchecked aside of mine into an authored file: a claim that carries no weight attracts no scrutiny, and then it sits being read as measured. Found by sweeping this corpus for decorative generalisations ("as everywhere else", "the usual") after they did. A disc test pins the draw order to[2,4,6,1,3,5]— the glows first — which is the order measured off the running game, so the measurement is now checkable rather than merely recorded.
Note this render also depends on the _eff fix
(ui-focus-and-effect-elements.md): before
it, the three glows were dropped as "focused-state records" and the splash would
have rendered as three bare logos.
What is not settled
- ❔ What makes a bundle a screen.
is_composableanswers "can this be drawn", not "is this a screen the game shows". Element count is a crude proxy (fragments are 2–5 elements) and has not been checked against anything. - ❔ The
.prmprimitives.palogo_eff0.prmis a full-screen element with pivot (640,360) and a single keyframe; nothing decodes.prmyet, so every composite is missing whatever they draw. On the splash the measured paint order puts it first, i.e. it is the backdrop. - 🟡 The splash render has not been diffed against a framebuffer capture. It is now possible to, which it was not before.