fix(video): match data-format 14 to format 13's number-type wildcard in GetTextureFormat - #860

Before submitting

Please read our contribution guidelines before opening a pull request:

➡️ CONTRIBUTING.md

By opening this pull request, you confirm that you have read and agree to follow the contribution guidelines.

What this fixes

GetTextureFormat in VulkanVideoPresenter.cs decodes a guest data-format + number-type pair into a Vulkan format. Formats 13 and 14 are the same 128-bit float layout and are handled together everywhere else this pair shows up:

• TryDecodeRenderTargetFormat in the same file: (13, 7) or (14, 7), (13, 0) or (14, 0).
• The Metal backend's mirrored table (MetalGuestFormats.DecodeTextureFormat, which the comment on that method says mirrors this exact function "case for case"): (13, _) or (14, _) => Rgba32Float.

In GetTextureFormat itself, format 13 has a real wildcard ((13, _) => R32G32B32A32Sfloat), but format 14 was only matched at number type 7:

(14, 4) => Format.R32G32B32A32Uint,
(14, 5) => Format.R32G32B32A32Sint,
(14, 7) => Format.R32G32B32A32Sfloat,

Any format-14 texture using a number type other than 4/5/7 falls through the whole switch to the unrelated final default (R8G8B8A8Unorm) instead of the 128-bit float format — wrong bytes-per-pixel and wrong interpretation for whatever texture hit that path. Given the other two tables agree 13 and 14 should behave identically, this reads like the 14, _ case was typed as 14, 7 when the block was duplicated from format 13's.

Fix is a one-line change, widening the same way format 13 already is:

(14, _) => Format.R32G32B32A32Sfloat,

Testing

GetTextureFormat lives on a private sealed class nested inside VulkanVideoPresenter, so it isn't reachable from the test project as-is (nothing currently covers it, including its existing cases) — didn't want to widen internal visibility just to test one line. Built the solution (dotnet build SharpEmu.slnx -c Release) clean and ran the existing VulkanPresentEncodeFormatTests suite, both pass. I don't have a title on hand that hits guest format 14 with an unusual number type, so I can't attach a before/after game log — the case is derived from the two parallel tables agreeing with each other, not from a repro.

Checklist

By submitting this pull request, you confirm that:

• I have read and followed CONTRIBUTING.md.
• I tested my changes or marked the testing section as N/A.
• I wrote this pull request description myself and did not paste AI-generated explanations.
• I listed the game(s) I tested (or marked the testing section as N/A).