ppsspp
ppsspp copied to clipboard
Pursuit Force graphic issues
What happens?
car run under road in some place, test on android, PC seem doesn't has this issues.
another issue, graphic glitches vulkan backend only. opengl and direct3d work ok.
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
PPSSPP version: ppsspp-v1.6.3-248-g098a7ffea-windows-amd64.7z ppsspp-v1.6.3-248-g098a7ffea-android.apk
this game use hundreds of bezier lines. like Acid 2 use hundreds of splines.
So there are two separate issues here - do they both happen only on Vulkan? Or does the mobile issue happen on OpenGL and Vulkan both, and the other issue happen only on Vulkan?
-[Unknown]
graphic glitches happen only on vulkan(PC and mobile).
car run under road test on mobile opengl backend, vulkan backend is not playable for graphic glitches.
We can avoid this bug(maybe second issue only) using the following fix.
StateMappingVulkan.cpp
key.depthClampEnable = gstate.isClippingEnabled() && gstate_c.Supports(GPU_SUPPORTS_DEPTH_CLAMP);
to
key.depthClampEnable = false;
Probably, the same issue as D3D11. D3D11: Specify DepthClipEnable = TRUE when creating rasterizer states… 480a05d
Hmm, but if the game specified that flag, it indicates to clamp depth to the [0, 65535] range. Maybe the flag is ignored when drawing beziers or something?
-[Unknown]
Weird. I don't have this problem on my phone using Vulkan. Instead I get a weird "mirroring" effect when I enable "Hardware Tessellation". The game is not playable on Vulkan without this option. The opposite is true with OpenGL. If I enable this option the game becomes super slow!
@leopard20 check the features tab in system information - your device may not even support depth clamping.
-[Unknown]
Right. It doesn't!
unchecked simulate block transfer, the game is running smoother.
when use low spline/bezier curves quality, car run under road in some place. medium and high work fine.
Ah, low quality is not spline/bezier. It's just drawing control mesh(no curve tessellation/evaluation). So it's just specification(not bug). However I fixed it and I will commit later.
@unknownbrackets Vulkan depth clamp issue is related to Vulkan driver bug or unsupported feature maybe.
I have experienced the same graphical issues on my machine on Vulkan. First on Linux (hinted in #10477) and now on Windows too.
Vulkan:
OpenGL:
As of 1.6.3-323
I can't start any game with Vulkan at all. My computer becomes unresponsive and after a few seconds I get:
Lost the Vulkan device! Try to continue?
Is v1.6.3-323-g945eab6fe the first build that stopped working? What's the last build that works?
Also - which positioning of the yellow is "correct"?
Can you try that same exact scene in the software renderer? It might be that we need to clamp depth at the fragment level to be correct (which is unfortunate.) It will help to know if the software renderer has the same glitch.
-[Unknown]
Last good: v1.6.3-220-g309036069
First bad: v1.6.3-221-g06340bfa9
The front part of the car is missing, maybe that's easier to find?
Before yellow roadblock (depth map)
OpenGL
Vulkan
After
OpenGL
Vulkan
I wonder if that error is caused by KhronosGroup/glslang#1418, if it's happening on PC.
What does depth look like using the software renderer? In theory, that's the correct depth.
-[Unknown]
Before
After
Okay, then probably OpenGL is correct. Since it seems like it renders mostly right in the software renderer, can you try making a GE debugger dump?
To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.
After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.
I can even try running this on a real PSP to compare (that's still experimental, though.) Then I could see what depth /should/ be for sure.
-[Unknown]
So I have to switch to Software Renderer, click Step Tex in the GE Debugger until the texture appears in the preview window, then Record and then Resume? UCES00019_0001.zip
Ah - unfortunately, that didn't capture anything.
It's probably fine to make the GE debugger dump using any backend. But something failed if it creates a 2KB file - this is the second time I've seen that now, there must be a bug causing it. But if you click do Record/Resume again, it should work after a couple tries at worst.
-[Unknown]
Backend: Vulkan Software Renderer: off
Again, I waited for the yellow roadblock to appear in the texture preview, Record -> Resume. This time theres actually stuff in the file.
Hmm, it seems to heavily use minz/maxz and viewport z params. Maybe something isn't dirtying properly, or else there's somewhere we're handling these depth params wrong.
Most of the drawing is done with the viewport centered on the first 50% of depth (0 - 16383), and with a maxz of 16383.
-[Unknown]
Do note that this is working fine with earlier builds.
Last good: v1.5.4-189-gc1a23658d
First bad: v1.5.4-197-gea50561c8
Right, so that points to depth clamping - #10454. But the question is, why. The PSP definitely clamps depth, but maybe we need to do it in the fragment shader for it to be accurate.
I think right now, we're deforming polygons when it clamps, perhaps, which is only okay in flat or mostly-flat cases.
-[Unknown]
How does this look with recent changes now?
-[Unknown]
test latest dev build, vulkan still have graphic issues.
use low spline/bezier curves quality, car run under road in some place, but not worse than before.
Everything is fine for me again. I couldn't test it since the Lost the Vulkan device! error but as of v1.6.3-482-g025e478d2
(last bad: v1.6.3-479-g637a17a66
) it's all working again and the graphics are correct.
I believe this is fixed, closing. Please reopen if not.
Apparently not, reopening.
Apparently still an issue, from Dakile on Discord, with GTX 980m:
https://cdn.discordapp.com/attachments/480103153803460614/551370781482024961/unknown.png
In the meantime, a workaround is to play using D3D9, for example.
I assume this is caused by #11399, and doesn't fall into the simple case 9859827 handles.
See here for a possible workaround (might break other games, I think I ran across one it would, but still might break less): https://github.com/hrydgard/ppsspp/issues/11399#issuecomment-423394932
-[Unknown]
Yeah this is still a thing even on the current git versions and the latest stable version. Tried out Pursuit Force Extreme Justice and the graphics are messed up all over the place. Playing with DX9 will make the game super slow for some reason (its because its falling back to software renderer).