DXT1 (108/137 textures in Base.xpr — the bulk of picture assets) decoded to
noise. Root cause found by RE: Xbox 360 BCn blocks store the two 32-bit words
of each 64-bit sub-block in the opposite order to the PC/DDS layout — colour
endpoints live in the HIGH dword, indices in the low one. The endian field
(k8in16) only fixes byte order within the 16-bit words; it does not reorder the
dwords, so without this every DXT texture transposed endpoints/indices → noise.
Isolation that led here:
- de-tile proven correct for bpb=8 (coherent per-block signature map; the
linear read is scrambled) — same faithful Xenos Tiled2D as the verified
bpb=4 ARGB path (green Acheron backdrop).
- inspecting a smooth region, coherent colour endpoints appeared only in
bytes[4..8], with the high-entropy indices in bytes[0..4].
Fix: swap_bc_block_dwords() swaps the two dwords within each 64-bit unit after
the byte-level endian swap, for every BCn format. Verified in the real Rust CLI:
weapon skins (rou_f001_wep_*) now decode to clean, recognisable images.
Viewer: DXT1 is fixed transparently (from_xpr2 feeds tex.data straight to the
GPU as Bc1). Also corrected the uncompressed path — post-swap k_8_8_8_8 is
[A,R,G,B]; reorder to [R,G,B,A] and upload as Rgba8UnormSrgb (was Bgra8, wrong).
Knob: XPR_NO_BC_DWORD_SWAP disables the swap for A/B validation.
KNOWN REMAINING: 16-byte blocks (BC2/DXT3, BC3/DXT5) and BC4/BC5 (DXT5A/DXN)
still need their alpha+colour half layout worked out — they decode to noise for
now. DXT1 + uncompressed + cubemaps are correct.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
405233e84f