Kurohyou 2(Yakuza 2) cutscene flickering and subtitles missing after update v1.13.1-130-g714afb46a

[lim2222]

Game or games this happens in

NPJH50562-Kurohyou 2 Ryu ga Gotoku Ashura Hen

What area of the game

All the cutscenes flickering and subtitles missing with both vulkan and gles, software rendering is normal.

What happens

https://youtu.be/2Q9mTaVWYFA

What should happen

GE frame capture

NPJH50562.ppdmp.zip

Platform

Android

Mobile phone model or graphics card

Mi 10T Pro android 10

PPSSPP version affected

v1.13.1-130-g714afb46a

Last working version

v1.13.1-118-g9437d5e3b

Graphics backend (3D API)

Vulkan

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try changing graphics settings to determine if one causes the glitch (especially speed hacks or enhancements/replacements.)
• [X] Include logs or screenshots of issue.

[ghost]

I cannot reproduce this on my Redmi note 9 Mali GPU.

[hrydgard]

Thanks, this is likely Adreno-specific. On my list to investigate it goes.

[dante3732]

Thanks, this is likely Adreno-specific. On my list to investigate it goes.

I have same on my PC. The video turns black at the moment when the characters speak and subtitles should appear. If disable subtitles, FMV work fine, but i don't know japanese language. Because of the subtitles, the screen turns black.

It regression after this build. https://github.com/hrydgard/ppsspp/pull/15772 On previous this build FMV and subtitles work fine.

[hrydgard]

Thanks for reporting that it's not just an Adreno issue. This game does need some more work indeed.

I have some planned improvements that might help this.

[unknownbrackets]

In the dump, it looks like this should reproduce anywhere that supports rendering to depth? Without this case, it renders correctly on NVIDIA desktop:

WARN_LOG_ONCE(color_matches_z, G3D, "Color framebuffer bound at %08x with likely intent to write explicit Z values using color. fmt = %s", params.fb_address, GeBufferFormatToString(params.fmt));

What's happening here is that the game temporarily uses the Z buffer as a color buffer (565) to temporarily render the subtitle. Then it renders from that as CLUT16 (which doesn't look like an attachment in the GE debugger...) which is meant to translate the black-to-white values to transparent-to-black.

In the GE debugger, it shows all blank. But the depth shows solid boxes where the letters are, instead of characters. It seems like alpha blending is not working when rendering to depth. Not sure why this isn't used properly as the texture, so that's a second issue.

After the CLUT16 renders (there are several, to create a black outline for the subtitle), it switches to texturing from the Z buffer address as 565. This is supposed to render to render the black-to-white, but with fixed ONE + ONE blending. All of this worked fine as a color buffer but is behaving incorrectly with depth.

Since the new strategy of compatibility is to use game-specific hacks for everything, I guess a new means of creating scene-specific game hacks will have to be devised. As shocking as it may be to some, this evidences that games in fact do not use a single rendering strategy throughout.

-[Unknown]

[hrydgard]

The color-to-depth mode is not a game specific hack. It detects this specific situation of binding a previously-depth-buffer region of memory as color, and if we have a handy framebuffer around that matches, we switch to this mode instead so writes get converted.

As you noticed that indeed does fail if the same buffer is then used for actual color, so more checks may be necessary. But since we have no possibility of aliasing color and depth buffers on top of each other on modern GPUs this kind of stuff is gonna be the only really efficient way to do it. The general way of handling cases like this would be full-on CPU readbacks, which are expensive.

Although, thinking of readbacks gave me an idea that yeah, we can do actual readbacks and uploads/writebacks to handle framebuffer aliasing. We just have to do them on the GPU instead, to a fake VRAM buffer there. Support for higher resolution will remain tricky though. And we will lose the ability to force higher color bitdepths (unless maybe we store additional color bits in some auxiliary buffer), so might have to implement dithering for things to look reasonable in these cases.

[hrydgard]

Hm, or we just extend the depth buffer tracking from that other PR, and include copies from color buffers..

Thanks for kicking my idea center into gear by some harsh criticism, needed sometimes...

I really don't want to do game specific stuff where it can be avoided.

[unknownbrackets]

Sorry if I'm harsh, but compat.ini continues to get larger, especially of late, and what removals there have been have largely been trades for other more recent compat hacks.

For the short term (and I suspect other games using Z as a temp buffer, which is quite common), avoiding it when blending is used should often work, as usually bloom or other things in the Z temp address are using blend for their effects.

-[Unknown]

[dante3732]

GPU: Avoid using depth buffers for blending #15845

Nice, it fixed subtitles in yakuza 2.

[hrydgard]

I've just merged an alternate fix for this, from https://github.com/hrydgard/ppsspp/pull/15858. Does everything still work?

[lim2222]

Yes,#15858 fixed everything,thanks alot.

[dante3732]

I've just merged an alternate fix for this, from #15858. Does everything still work?

Yep