Kidou Keisatsu Patlabor - Kamubakku MiniPato Black screen in beginning

[sum2012]

Game or games this happens in

ULJS00026

What area of the game

Beginning

What happens

Black screen

What should happen

Should no problem.
Only softgpu no problem

GE frame capture

ULJS00026.zip

Platform

Windows

Mobile phone model or graphics card

Nvidia Geforce 710

PPSSPP version affected

ppsspp-v1.14.4-617-gfebba1886-windows-amd64

Last working version

None

Graphics backend (3D API)

Vulkan

Checklist

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

[sum2012]

I test menu also have problem.
ULJS00026-2.zip

[sum2012]

On hand build test:

DX9:
GOOD
v1.14
BAD
v1.14.1

Opengl ,Vulkan,DX11
GOOD
v1.12.3
bad
v1.13

[sum2012]

@unknownbrackets
Opengl ,DX11 git bisect result:
7d00b6c
in #14833

Vulkan git bisect result:
273b9a3
in #14833

[sum2012]

@unknownbrackets
DX9 git bisect result:
3e77cb1
in #16615

[hrydgard]

Okay, so likely another depth clipping edge case. Good find!

[sum2012]

@hrydgard There is is a easy D3D9 hack fix.
Revert 3e77cb1 of ShaderManagerDX9.cpp change

[hrydgard]

Yeah, but I think we want to try to understand why that broke - the game must be doing something unusual. So it needs looking into.

[unknownbrackets]

Menu framedump on a PSP:

Software is close, but has some error on one of the buttons:

None of the buttons show at all on Vulkan. The first draw at 8/18 (for a shadow) uses:

• Has depth clamp/clip enabled.
• Has a full min/max Z range (0000 - FFFF)
• Uses src >= dst depth testing
• Also uses alpha testing (a > 0) and blend (fixed zero + 0x404040)

Then it does the same thing, slightly offset X/Y but same Z at 9/18 for the actual button. This time, there's no blend.

The depth value in that area of the screen is 65435, and the incoming depth is 65445. So it should pass. And even setting it to ALWAYS doesn't help, so it's not the depth test.

The original Z is 0. World Z is identity, view Z is world.z * 0.999985 - 20.499512, then projection Z is view.z * -1.020172 - 2.020142 while projection W is view.z * -1. By my math, that means pre-viewport Z is 18.892886156064 and W is 20.499512, resulting in a Z/W of 0.9216261419327445 or so. Z is larger than negative W, so it should not clip.

Viewport is unusual here. Z scale is 0. Offset is 65445. So actually, the projected Z "doesn't matter" because Z is being forced to a fixed value anyway. That doesn't change whether it clips, but is interesting.

And that's the problem: the Z scale of 0 causes us to calculate confused depth range values.

-[Unknown]