[ FF7 ] Magenta Overcast on all FMVs When Using Vulcan Driver on Borderless or Full Screen

[gtao725]

Describe the bug
With or without mods turned on, in 7th heaven mod manager(4.2.0.33), change game driver settings to use Vulcan Graphics API, then Window Mode to either Borderless or Full Screen. Start a NEW GAME in FF7, when the opening FMV plays, you can see a Magenta Hue overcast on the FMV.

Expected behavior
FMVs should not have a Magenta hue overcast over them.

Screenshots
See below video
https://youtu.be/sJ_hfuR6F0o

GPU (please complete the following information):

• Nvia GeForce RTX 3070ti
• Driver Version 572.16
• FFNx Version Latest Canary

Additional Info
Bug does not happen with Vulcan running in Windowed modes or with other drivers such as OpenGL, DX11/12.

[julianxhokaxhiu]

Thanks for reporting the issue. While trying to open the youtube link says the video is private and I can't see it. Is there any way you can put it to public?

[gtao725]

Thanks for reporting the issue. While trying to open the youtube link says the video is private and I can't see it. Is there any way you can put it to public?

Hello @julianxhokaxhiu sir, it is now public. Pls try again. Srry it was still waiting out its schedule to go public.

[julianxhokaxhiu]

Still returns that the video is private :(

[gtao725]

Still returns that the video is private :(

hi @julianxhokaxhiu , maybe try it in a Chrome incognito window or Edge InPrivate window? I think it might be your cache. Seems fine from my end, tried on multiple devices all fine. Anyways below are some screenshots in case you still cant view the video:

[julianxhokaxhiu]

Thanks I was able to repro, Moved this conversation to discussion by mistake but I'll treat it as an issue. I'll keep you posted.

[gtao725]

thx @julianxhokaxhiu ! Just progressed the game a bit further on Vulcan in windowed mode and found another bug. After defeating Guard Scorpion and escaping Reactor 1, a short FMV is supposed to play as team blows up the exit door and Wedge runs out with his ass on fire lol. The game locks up right at where the exit door is about to explode. Again tested on non Vulcan drivers and the issue is not present.

[julianxhokaxhiu]

Ok I found that the bug mainly comes from the NTSC-J code added from @ChthonVII If I disable this portion of the code, the movie looks fine for some unknown reason to me. I think all the other issues you are finding are probably related to this. So I need his help to figure out what he's doing on that portion of code to get this fixed properly.

[julianxhokaxhiu]

Attaching as well a frame dump in case you want to debug it using RenderDoc
ff7-bor.zip

[gtao725]

Many thx @julianxhokaxhiu and @ChthonVII !

[ChthonVII]

Unfortunately, I'm not presently able to compile FFNx. (Old PC died and I haven't got around to getting FF7 working again.) So, I'm shooting blind here. Also, I'm about 95% sure I was running vulkan fullscreen back when I wrote that. So this is a regression of some kind, or a bad driver.

Given the settings shown in the screenshot, and the fact that dummying out the color gamut metadata detection fixes it, I figure that the problem must be in the "if" stanza starting on line 197 of FFNx.frag.

Let's start by confirming that supposition by commenting out that stanza and see if the problem goes away.

Assuming the problem is indeed in this stanza, we've only got two function calls in there that modify the color: GamutLUT() and QuasirandomDither().

I think QuasirandomDither() is the more likely suspect, so let's start there. Perhaps the call to textureSize() on line 200 of FFNx.frag is giving us garbage in fullscreen vulkan, and only in fullscreen vulkan. (Which would be a regression in BGFX or a driver problem.) That might lead to QuasirandomDither() doing wacky stuff, only in fullscreen vulkan. To rule that in/out, try commenting out just line 201 and see if that makes a difference.

If QuasirandomDither() wasn't it, then our other suspect is GamutLUT(). The only possibility I can think of here is that maybe it's wrapping around the red value when sampling the LUT. (I can't imagine why that would happen only in vulkan fullscreen, but I'm out of ideas here.) To work around that, try modifying GamutLUT() in FFNx.common.sh as follows:

Add a saturate to line 205:
vec3 ceilweights = saturate(temp - floors);

Add the following after line 205:

// driver might not correctly sample a 1.0 coordinate
// so we are going to add a just-under-half-step offset to red and green, then increase their divisors by 1
// This should get us a slightly lower coordinate within the same pixel
floors = floors + vec3(0.4999, 0.4999, 0.0);
ceils = ceils + vec3(0.4999, 0.4999, 0.0);
floors = floors / vec3(4096.0, 64.0, 64.0);
ceils = ceils / vec3(4096.0, 64.0, 64.0);

Replace the stanza on line 207 with:

vec3 RfGfBf = (texture2D(tex_10, vec2(floors.b + floors.r, floors.g))).xyz;
vec3 RfGfBc = (texture2D(tex_10, vec2(ceils.b + floors.r, floors.g))).xyz;
vec3 RfGcBf = (texture2D(tex_10, vec2(floors.b + floors.r, ceils.g))).xyz;
vec3 RfGcBc = (texture2D(tex_10, vec2(ceils.b + floors.r, ceils.g))).xyz;
vec3 RcGfBf = (texture2D(tex_10, vec2(floors.b + ceils.r, floors.g))).xyz;
vec3 RcGfBc = (texture2D(tex_10, vec2(ceils.b + ceils.r, floors.g))).xyz;
vec3 RcGcBf = (texture2D(tex_10, vec2(floors.b + ceils.r, ceils.g))).xyz;
vec3 RcGcBc = (texture2D(tex_10, vec2(ceils.b + ceils.r, ceils.g))).xyz;

(Please forgive any errors I made coding blind here.)

If neither of those suspects pan out, then I'm afraid I'm out of ideas for now.

[julianxhokaxhiu]

If you download my RenderDoc dump you can also see what is going on under Vulkan on the GPU, so it could help you deriving some hypothesis. I'd suggest having a look, might be a shot in the dark but it could help to isolate what is going on.

[julianxhokaxhiu]

Looking back at BGFX commits the only one I found which might be related to this issue is this MR: bkaradzic/bgfx#3020 ( which touches the way texture coordinates are calculated ). Something worth checking.

[julianxhokaxhiu]

I'm trying to update the bgfx stack to the latest commit available today and keep you posted.

[julianxhokaxhiu]

Ok bumping the stack to the latest didn't change anything, but at least now are on par. So feel free to scout anything that makes sense to you. I'll stay put until further feedback is provided.

[ChthonVII]

Ok after doing some tests I can confirm that the issue is in this call:

FFNx/misc/FFNx.frag

Line 198 in a705a42

color.rgb = GamutLUT(color.rgb);

I'm afraid I'm right and truly puzzled. Since that function is mostly concerned with a fixed-size LUT texture, it makes no sense that the behavior changes when vulkan goes to fullscreen mode. I suspect a regression in BGFX. (Either that or nVidia driver bug.)

To test the "regression in BGFX" theory, try rolling back to the BGFX version that FFNx used back when NTSC-J was first implemented and see if that makes a difference. (Again. I'm 95% sure I was using the vulkan driver back then.)

I guess also try filing a bug report for BGFX and see if they have any insight.

As for the GamutLUT() function:

• If the changes proposed in my previous post work correctly outside of vulkan fullscreen, then I suggest keeping them. They may not help here, but they might fix stuff on some problematic video drivers we don't know about. (The effect of these changes is to make sure that we never sample from the LUT texture at a 0.0 or 1.0 coordinate; it's always fudged a bit towards the center of the pixel.)
• I was going to suggest clamping the input, but it already does that. So scratch that idea...
• Assuming a wrapper exists for it in BGFX's shader language, we could try rewriting the function to use texelFetch() rather than texture2D().
• I have a suspicion that BGFX might be doing some unwanted scaling or mip-mapping to our fixed-size LUT texture. Or perhaps buggy anisotropic sampling? Perhaps we can mess with what Renderer::createTextureHandle() is telling BGFX to do?
  • Printf the img->m_width, img->m_height, img->m_numMips, and img->m_numLayers detected from the png file to make sure they're not insane. (Should be 4096x64, 1 layer, no mips.)
  • Mess with the flags? BGFX's documentation for createTexture2D() tells us the default sampling flags are "linear" and "wrap," and tells us to go look at documentation that doesn't exist for the other flags. They're in a header file though, and we can kind of guess what they do.
    • Passing flags BGFX_SAMPLER_MIN_POINT and BGFX_SAMPLER_MAG_POINT to createTexture2D() might fix it.
      • This is probably not desirable for anything other than LUT textures, so createTextureHandle() would need an extra parameter to tell it when these flags are called for.
      • Even if this doesn't fix it, this is "correct," so we should keep the change anyway.
      • Might as well set BGFX_SAMPLER_MIP_POINT while we're at it, even though this texture has no mip-maps.
    • Passing flags BGFX_SAMPLER_U_CLAMP and BGFX_SAMPLER_V_CLAMP to createTexture2D() might fix it.
      • But it might also mask the problem by giving us something less wrong without really fixing the bug. With the changes from my prior post, we should definitely never be doing an out-of-bounds sample. Using the clamp flags may give us a less objectionable wrong color without resolving whatever is causing us to sample from the wrong spot in the first place.
      • I think this is probably OK as a global change. We should never be sampling out-of-bounds anyway, but, if we do, this probably gives the least bad results.
      • If changing to point sampling fixes the problem, then that suggests buggy anisotropic sampling, so we'd probably want this as a global change to mask that bug.

[julianxhokaxhiu]

As much as it might seem weird, I'm not sure what happened between yesterday and today but I am no more able to reproduce the issue. I did try Borderless and Fullscreen and both work fine now under Vulkan.

The only change I did recently was upgrading my Nvidia drivers to 572.16 and restoring factory settings on the Nvidia Control Panel. Might be something stupid but something worth checking.

[julianxhokaxhiu]

Oh wait, I found what is no more triggering it. When you enable flags to show the driver version ( or graphics API ) then I am able to have the purple color, otherwise if I do not enable that it works just fine under Vulkan! Can you @gtao725 please try on your end as well? Update to the latest FFNx Canary via 7th, hit reset defaults on the Game Driver window then set Vulkan and Borderless only. See how that goes and let us know.

[gtao725]

Yep, turning off all the overlays fixed the overcast problem. But the following issue still exists under vulcan:

"Just progressed the game a bit further on Vulcan in windowed mode and found another bug. After defeating Guard Scorpion and escaping Reactor 1, a short FMV is supposed to play as team blows up the exit door and Wedge runs out with his ass on fire lol. The game locks up right at where the exit door is about to explode. Again tested on non Vulcan drivers and the issue is not present."

Maybe you could try reproduce with below save?
https://drive.google.com/file/d/1fJVJ5TzFdctvWNg3ipROn5qBM5c2VjUH/view?usp=drive_link

Just load up any of them using Vulcan gfx driver, defeat guard scorpion and run out of reactor 1, wait for the fmv where the door blows open and see if it locks up.