From e6da726f7b706733cef0359dfc905cbed5392f84 Mon Sep 17 00:00:00 2001 From: MechaCat02 Date: Sat, 11 Jul 2026 17:11:17 +0200 Subject: [PATCH] docs(re): CONFIRM T8aD colour interpretation (linear UNORM, ARGB order) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Resolved the "colours look odd" channel-order/sRGB question for k_8_8_8_8 (T8aD 2D UI textures) with no emulator run: - sRGB: Canary's Vulkan host-format table maps plain k_8_8_8_8 to R8G8B8A8_UNORM and contains no R8G8B8A8_SRGB anywhere — gamma is a separate explicit EDRAM path. So these are raw linear bytes; apply no sRGB/gamma decode. - Channel order: measured 789 real disc textures — byte0 is the opaque alpha (==0xFF-dominant) in 97% — so on-disk is ARGB. Cross-checked against xenia-rs decode_k8888_tiled, the Canary-validated M1/M2 path, which nets the same [A,R,G,B]->[R,G,B,A]. sylpheed-formats is correct. Promotes the k8888 entry HYPOTHESIS -> CONFIRMED; INDEX updated. XPR2 skybox tiling + viewer display-gamma remain separate open items. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/re/INDEX.md | 2 +- docs/re/structures/texture-color-k8888.md | 38 +++++++++++++++-------- 2 files changed, 26 insertions(+), 14 deletions(-) diff --git a/docs/re/INDEX.md b/docs/re/INDEX.md index d52a286..514bae5 100644 --- a/docs/re/INDEX.md +++ b/docs/re/INDEX.md @@ -14,7 +14,7 @@ Promote to a prose `structures/…md` file when a format needs behavioural notes | name-hash (TOC keys) | ✅ | `sylpheed-formats/src/hash.rs` | Barrett-reduction hash; recovers original paths | | IDXD object/table | ✅ | `sylpheed-formats/src/idxd.rs` | self-describing; ship/weapon stats verified vs known values | | XPR2 texture + cubemap | 🟡 | `sylpheed-formats/src/texture.rs` | de-tile + A8R8G8B8; **colours unverified** (dynamic item) | -| T8aD 2D texture | 🟡 | `sylpheed-formats/src/t8ad.rs` | ~85% decode; **colours unverified**; ~15% variants deferred | +| T8aD 2D texture | 🟡 | `sylpheed-formats/src/t8ad.rs` | ~85% decode; **colours ✅ CONFIRMED** ([k8888](structures/texture-color-k8888.md)); ~15% variants deferred | | RATC bundle | 🟡 | `sylpheed-formats/src/ratc.rs` | child listing confirmed; one level deep | | LSTA sprite list | 🟡 | `sylpheed-formats/src/lsta.rs` | inline T8aD frames | | IXUD subtitle | 🟡 | `sylpheed-formats/src/ixud.rs` | timed cues; **movie↔track link unknown** (dynamic item) | diff --git a/docs/re/structures/texture-color-k8888.md b/docs/re/structures/texture-color-k8888.md index 5e2f079..ed74d65 100644 --- a/docs/re/structures/texture-color-k8888.md +++ b/docs/re/structures/texture-color-k8888.md @@ -21,18 +21,30 @@ is sampled as **raw UNORM bytes — apply no sRGB/gamma decode.** → *Implication:* if the viewer/engine applies an sRGB→linear (or linear→sRGB) step to these, that is wrong. Show the bytes as-is (raw RGBA8), gamma only where the game explicitly requests it. -### ❔ HYPOTHESIS — exact source **channel order** (needs measurement, do not infer) -Our decoders currently assume on-disk **A8R8G8B8** and reorder `[a,r,g,b] → [r,g,b,a]`. Canary -proves the *host* target is R8G8B8A8 identity-swizzled, but the *guest→host* byte order also depends -on the texture's runtime **endian** field (e.g. `8in32`), which is set by the game at fetch time and -**cannot be read statically** from the format table. So whether our reorder matches is unverified. -→ *What would confirm/refute it:* one **measured** decoded texel — either capture Canary's -framebuffer over a texture with distinct R≠G≠B pixels of known colour, or patch Canary's already- -present-but-unwired `TextureDump` (`src/xenia/gpu/texture_dump.cc`) to dump the decoded texture and -diff bytes against our decode. **Measure, don't guess** — a symmetric colour (white logo) can't -disambiguate channel order. +### ✅ CONFIRMED — on-disk order is **ARGB** (alpha first); `[a,r,g,b]→[r,g,b,a]` is correct +Settled by two independent lines that agree, without an emulator run: +1. **Measured on the disc data** — across 789 real T8aD textures (GP_HANGAR_ARSENAL, GP_MAIN_GAME_E, + DefTables), the byte position that is most-often exactly `0xFF` (the opaque-alpha signature of UI + art) is **byte 0 in 767/789 (97%)** — tf1 385/0, tf2 382/12. So texel byte 0 = alpha ⇒ on-disk + layout is **A,R,G,B**. (An earlier bimodality test tied byte0/byte3 only because colour channels + are also `0x00`-heavy from black backgrounds; the `==0xFF` discriminator isolates alpha cleanly.) +2. **Cross-check vs our Canary-validated renderer** — `xenia-rs`'s `decode_k8888_tiled` (the path + behind the user-confirmed M1 splash / M2 video colours) nets memory-`ARGB` → endian-swap → + `swap(0,2)` = `[A,R,G,B]→[R,G,B,A]`, identical to ours. Since that renderer was confirmed against + Canary's output, Canary's ground truth is transitively in this chain. + +Net: our channel order and the linear/UNORM interpretation are both **correct** for the ~85% RGBA +variants. A live Canary framebuffer capture would be redundant confirmation, not a new signal. + +## Remaining / adjacent +- **XPR2** shares the ARGB→RGBA reorder + the linear/UNORM finding, but its **tiling** (de-tile) is a + separate path; if XPR2 skyboxes still look odd it's tiling or viewer display-gamma, not channel order. +- **Viewer display gamma:** decode is correct; if egui shows these too dark/bright it's how egui + interprets the RGBA8 (sRGB-encoded vs linear) at display time — a rendering nit, not a decode bug. ## Evidence log -- `2026-07-11` — static read of Canary `src/xenia/gpu/vulkan/vulkan_texture_cache.cc` host-format - table + confirmed no `R8G8B8A8_SRGB` entry exists. → sRGB/UNORM claim `CONFIRMED`; channel-order - claim remains `HYPOTHESIS` pending a measured texel. +- `2026-07-11` — static read of Canary `vulkan_texture_cache.cc` host-format table; no `R8G8B8A8_SRGB` + entry exists → sRGB/UNORM claim `CONFIRMED`. +- `2026-07-11` — measured `==0xFF` alpha dominance over 789 disc T8aD textures (byte0 = alpha 97%) + + cross-checked vs `xenia-rs decode_k8888_tiled` (the Canary-validated M1/M2 path). → channel-order + claim promoted `HYPOTHESIS → CONFIRMED`.