Sylpheed/docs/re/structures/ui-8ax-fullres-background.md

✅ pteff04 / pteff05 — the full-resolution background, once dropped as 8AX

Status: ✅ RESOLVED 2026-08-29. This page's two questions are both closed and it is kept for the evidence, not as an open item.

• Which of the two backgrounds does the game draw? — the full-resolution one. Measured against a capture; the section below stands unchanged.
• Why did ours drop it? — because 8AX is not a name. It is three bytes of the preceding record's payload (38 41 58) that happen to be printable ASCII, and our backwards printable-run scan preferred them to the name the format states in its opt block. Decoded, with a disc-wide check, in ratc-child-names.md; ratc::parse now reads the stated name and screen render draws the background on all five screens.

⚠️ Read the rest of this page with that correction in mind. It was written while 8AX was believed to be a name the game uses, and says so in several places — "the texture is registered as 8AX", "the T8aD behind its opt link is registered under the name 8AX". The opt link was never the problem; the opt block was the answer, sitting unread three bytes away.

_{Original status line: 🟡 a real name-resolution gap, currently harmless to look at, and the obvious fix would make the render worse. Found by auditing what screen render silently omits on the port's five screens.}

What screen render drops, and why

sylpheed-cli screen render reports its omissions. On the five screens the port needs, every one is accounted for except two:

screen	not drawn	reason
title (4)	ptlogo1×2, ptlogo2×2	kind & 0x4 ghost instances — the draw capture shows one quad per wordmark
	pteff00.prm, pteff02.prm	.prm primitives, off without --primitives
	ptloop01.rat, ptloop02.rat	loop* animations, off without --animated
	pteff04.t32	⚠️ unexplained — this page
main menu (5), EXTRAS (6)	as above, plus pteff05.t32	⚠️ same
splash (10, 11)	palogo_eff0.prm	primitive

pteff04/pteff05 are kind = 0x0, one keyframe, rest a = 255, and pivot (640,360) — i.e. a full-screen, fully opaque element. Exactly the shape of the defect the port agent reported (an element the game draws that we omit).

The cause: the element's name and its texture's name differ

Both names occur twice per bundle, the same as pteff03.t32, which resolves fine. The difference is what follows the opt link:

pteff03.t32   @0x4661a4   opt  →  T8aD          ← resolves
pteff05.t32   @0x0e2035   opt  →  8AX  T8aD     ← the sprite is named 8AX

Hex at 0x0e2035:

opt  ....  70 74 65 66 66 30 35 2e 74 33 32 00  38 41 58  54 38 61 44
           p  t  e  f  f  0  5  .  t  3  2  \0  8  A  X   T  8  a  D

So the declaration says pteff05.t32 while the T8aD that follows is registered under 8AX. compose does build.sprites.get(sprite) and, on a miss, hits a silent continue. 8AX is a 1280×720 texture and appears in all six title-family bundles (a60fcb85, a715f485, a81c1d85 and the three JP twins); it is a sprite in builds 4/5/6 and never an element.

✅ Why it does not currently show

The same artwork is already on screen. ptbase.t32 is 640×360 and its element draws at 200 %, and the background our render produces is pixel-identical to 8AX in every patch sampled:

patch	capture	our render	8AX
top-left	4.5, 9.4, 19.5	17.7, 29.7, 46.7	17.7, 29.7, 46.7
top-right	4.4, 9.0, 18.2	17.2, 28.2, 43.8	17.1, 28.2, 43.8
bottom-left	3.5, 6.0, 11.1	13.6, 20.5, 31.2	13.6, 20.5, 31.2

Directly: ptbase upscaled 2× against 8AX is mean abs diff 2.05 (max 80), not byte-identical. They are the same art at two resolutions — 8AX is the full-res copy, ptbase the half-res one the element scales back up.

⚠️ So do not "fix" this by drawing it

Resolving pteff05 → 8AX and drawing it in addition to ptbase would double-draw the background — an opaque full-screen layer over an identical one. It would not be visible as a doubling, which is worse: it would silently cost fill and hide any future change to either layer.

✅ And that is now the recommendation, not just an option: use 8AX at 1:1. The detail test above says the game's background carries 8AX's full-resolution detail, so upscaling the 640×360 ptbase 2× is wrong, not merely softer. ⚠️ Still do not draw both — an opaque full-screen layer over an identical one costs fill and hides any later change to either. ptbase's element carries the keyframes, so a consumer needs its timing with 8AX's pixels.

✅ Settled statically: the game draws the FULL-RES 8AX

This was parked as "needs a per-draw capture". It did not — the two candidates carry the same art at two resolutions, so what separates them is the detail 8AX has that an upscale cannot. Compute 8AX − upscale(ptbase) and ask whether the live capture contains it. tools/re-capture/eightax_detail_test.py, output at data/eightax-detail-test.txt.

Both candidates are first mapped into the capture's tone domain with the measured gamma (tone curve); without that the capture's residual is dominated by the tone difference and the test is blind.

screen	corr	control (shift 7 px)	control (flip)	ceiling	% of ceiling
main menu	+0.0475	+0.0032	−0.0075	0.070	68 %
title	+0.0634	+0.0095	+0.0086	0.094	68 %

The "ceiling" is what a clean "8AX is drawn" would give, sd(8AX-only detail) / sd(capture residual) — the 8AX-only detail is small (sd 1.9–4.1) against everything else that differs (sd 27–43), which is why the absolute correlation is small and why the controls matter more than the magnitude.

Two independent screens both land at 68 % of ceiling, 7–15× their matched controls. The controls preserve the spatial correlation structure and destroy only the alignment, so they are what "no signal" looks like here.

🔴 An earlier, cruder version of this test does NOT support the conclusion

A pixel-pair test (a 2×-nearest upscale has identical adjacent columns) gave ratio 0.00 for nearest, 0.60–0.72 for bilinear/bicubic/lanczos, 0.98 for native 8AX, and 1.01 for the capture — apparently decisive. It is not: additive noise raises both terms equally and pushes any ratio toward 1. Fitting a noise term, both "native + noise ≈ 1.2" and "bilinear upscale + noise ≈ 1.8" reproduce the observed numbers. Recorded because the number looks conclusive and is not.

⚠️ What it still does not show

Whether ptbase is also drawn underneath. 8AX is ~86 % opaque and carries the same art, so it would hide it either way. The observable fact is that 8AX's detail reaches the screen.

❔ Not established

• The capture is ~4× darker than the render in these patches (4.5 vs 17.7), and not by a constant ratio. That is a separate colour/gamma question, untouched here.