[Render] Messy FMV (5 Splits) (was Green FMV)

[BenoitAdam]

Happens on :

• Demolition Racer
• THPS
• Evil Dead
• The Flintstones
• Resident Evil 3
• Test Drive 6

And many games with FMV

I believe YUV422 needs implementation (CMPR and/or RGA8)

[skmp]

They also likely use planar textures to display these, which were removed in the psp port, before the wii port was ever a thing

[BenoitAdam]

short changes, a bit better but still not right, will dig into that later

commit 7a5d60b

commit bb58a12

gxRend: add YUV422 FMV decode (CMPR/RGBA8) via fmv_format, fix UV byte order

- Add fmv_format global (0=GX_TF_CMPR, 1=GX_TF_RGBA8) to select the Wii
  texture format used for YUV422 FMV frames.
- Implement YUV422_to_CMPR_Planar/Twiddled: decode UYVY->RGB565 and
  pack into GX DXT1 8x8 super-tiles (4x 4x4 blocks), using min/max
  luma anchor selection + nearest-palette assignment per pixel.
- Implement YUV422_to_RGBA8_Planar/Twiddled: decode UYVY->RGB888 and
  pack into GX RGBA8 4x4 tiles (AR + GB 32-byte sub-tiles).
- Wire both paths into case 3 (YUV422) of the texture conversion switch,
  replacing the old RGB565 stub.
- Fix decode_bytes / DCFlushRange sizing: RGBA8 needs w*h*4, CMPR needs
  w*h/2; previous w*h*2 default under/over-allocated and under-flushed
  the GX texture cache for these formats.
- Fix major byte-order bug: DC YUV422 word layout is [Y0][U][Y1][V]
  (low->high byte), not [U][Y0][V][Y1] as originally assumed. Wrong
  order fed near-zero "U/V" into the YCbCr->RGB formula instead of
  neutral (128,128), causing strong green-dominant output. Fixed in
  the planar/twiddled converters, the legacy Plannar<422> template,
  and the debug printf mirrors.
- Fix twiddled chroma/luma byte swap: low byte = Y, high byte = U/V
  per 16-bit "Y0U"/"Y1V" word, previously read backwards.
- Add DEBUG_MESSAGE()-gated [YUV] logging: texture dims/scan order,
  raw source words, planar- and twiddled-style decoded Y/U/V + RGB565,
  and first bytes of the encoded CMPR/RGBA8 output, for diagnosing
  remaining FMV corruption in Dolphin's console.

Status: green dominance reduced but FMV still not fully correct;
further debugging needed (possibly remaining twiddle indexing or
chroma subsampling alignment issues).

[BenoitAdam]

Green FMV has been resolved, now FMV can be seen but they are messy, often displaying 3 or 5 times, and using 50% of the screen

Test Drive 6 (Pitbull Syndicate FMV ) :

Bomberman online is the only game that FMV is looking in good aspect

[BenoitAdam]

Bomberman colors fixed, just needed to swap RED/Blue

[BenoitAdam]

Claude Code solved a bit this :

I added a tunable g_yuv_src_stride_override (near fmv_format, gxRend.cpp ~line 1208) that lets the YUV planar→CMPR source read use a different row stride than the destination texture width, without touching anything else. Currently 0 = original behavior (unchanged).

Set it to 640 (the real video width implied by the UV crop math from the original analysis) and rebuild. If that doesn't fix it, try 768 or 896 next — those are the next most likely "real" stride candidates. This directly tests whether the source is being read with the wrong row pitch, which would explain the diagonal-drift-and-wrap pattern in the one real-VRAM sample I did manage to capture.

Test :
int g_yuv_src_stride_override = 640 = IT WORKS ! (but buggy in bomberman now)
int g_yuv_src_stride_override = 768 = it doesn't work (also buggy in bomberman)
int g_yuv_src_stride_override = 896 = it doesn't work (also buggy in bomberman)

Root cause found: The YUV422 texture decode in gxRend.cpp was reading source pixel rows using the declared, power-of-two-padded texture width (1024) as the row stride — but the real video data Test Drive 6 wrote into VRAM is only 640 pixels wide per row. Every row read was offset by the leftover 384px, so each successive row "walked" further into the wrong place, eventually wrapping around — which is exactly why the picture looked like several identical copies tiled side by side (you were seeing the same narrow strip of real image data re-read at shifted, wrapping offsets). You confirmed this directly: hardcoding the read stride to 640 fixed Test Drive 6. Bomberman's texture has no such padding (real width = declared width = 512), so the same hardcoded "640" broke it.

The fix: rather than hardcode a constant, I found that the Dreamcast actually has a real hardware register for exactly this — TA_YUV_TEX_CTRL (already tracked elsewhere in this codebase, in dc/pvr/pvr_if.cpp, for a different feature, but never connected to this renderer). Its low 6 bits encode the real video width in 16-pixel units (real_width = (bits[5:0] + 1) * 16). I wired gxRend.cpp's YUV decode (case 3, ~line 1790) to read this register and compute the real stride per-texture, with a safety fallback to the old behavior (use the declared width) if the register doesn't describe something smaller. I also added TA_YUV_TEX_CTRL=... real_w=... to the existing [YUV] debug log line so we can directly verify the computed value.

[BenoitAdam]

Bomberman intro and test drive 6 intro both working

Bomberman main title video still buggy for now

[BenoitAdam]

Bomerman main title video is ok

Closing this one to open a new issue with more specific FMV Related problems