Remaining range culling problems #17397
Comments
|
The person in question says they're using a Samsung Galaxy A04E, which has shaderClipDistance and shaderCullDistance for Vulkan. GLES doesn't support clip/cull, though. That said, both frame dumps look the same as a PSP even when forcing off those. If I force off GPU_USE_VS_RANGE_CULLING, it does make one of the framedumps incorrectly differ from the PSP. #17397_NPUZ00179_nova_culling.zip Might need a better frame dump. Hard to imagine this happens in the game, but there was a homebrew that had someone similarly complain and the actual homebrew had the problems on a real PSP. Maybe it's some math issue. -[Unknown] |
|
Also the same with an additional frame dump: In this one, I assume the wall would be drawn by 4/39. It appears to match rendering on a PSP... -[Unknown] |
|
As you say, if you forcibly disable range culling in the code, we do indeed get what's almost certainly the intended image. Maybe some subtle CPU bug is missing to set the correct clipping flag? Or not saved in the dump correctly? Or, it's actually never set by the game and PPSSPP resorts to the wrong default? |
|
Noting here for clarity - that's only if I force us never to range cull. The PSP GE (at least as far as I've seen) always range-culls. There was a time when I thought that it didn't range cull when depth was clamped, but I was wrong - it was only when triangles were clipped against negative Z and said clipping put them within X/Y range. Since learning that I've found no way to reproduce a scenario where range culling doesn't happen. The way the registers work, it really seems like the GE can only deal with rasterization within its fixed 12.4 space, and simply discards things that go anywhere outside that. The software renderer (unlike Vulkan/GL which get it subtly wrong and also clip against W which is wrong and can result in over and under culling) should reproduce the negative Z clip scenario decently well. The frame dumps look the same with and without the depth clamp / near Z clip flag. It would have to be down to the verts or something. I did search for reviews quickly on this game. They're scant, but not very positive. Maybe it's more possible than I thought before that it was just a buggy mess... in which case, maybe this is a hack that makes the game better because it was a lazy iPhone port, although less faithfully emulating the actual PSP experience. -[Unknown] |
|
It makes some sense that it can only deal with raster coordinates in that small coordinate system, I guess it saves on gates in the chip to reduce those counters as much as possible. Anyway, this is weird. Because when actually playing the game on hardware and not replaying our framedumps, for whatever bizarre reason, it does seem like the bad culling isn't happening. Here's footage from what appears to be a real PSP, and there are no signs of the culling: |
|
Where are these issues actually seen, though? I kinda wish I'd bought this when the store was still available, I guess. I had some save state in some early part of the game, loading it in another mini obviously doesn't let me go very far, but I don't see any of this happening walking near walls, etc. -[Unknown] |
|
If you post the save state, I'll load it up on a phone with this GPU and try it. Yeah there's no way to actually get this legally now is there, at all? Kind of abandonware... |
|
Well, actually, maybe it's still possible on a PS3 or Vita if you fund a wallet, hm. If it's still listed. -[Unknown] |
|
Hm, I tried to load the savestate on top of psp-flower (by replacing one), and the result was a crash in PspOskDialog::DoState for some reason, which we should probably fix: I'll try loading it on top of something else.. |
|
Huh, I'm realizing that I don't think we use it pretty much anywhere else than in the old-version fallback for PSPOskDialog::DoState though. Though hm, fixing it might mean not loading old saves made on the same platform, just to be able to load old PC saves with this on Android. ugh. |
|
Alright, got it loaded up, and indeed, not seeing much in the way of culling issues on the device. Not sure what conclusions to draw here, as it looks ship-blockingly bad in the video above.. |
|
I guess the next thing to try is to ask someone with the game to make a new statestate in an affected location on an affected device.. Though, feels like we'd get similar results to the framedump, that it'd weirdly reproduce on both platforms. Anyway, if we assume that the game is just broken we could view disabling range culling as an "enhancement" here and just do it... |
|
@hrydgard I have this game on an affected device, and found this issue through searching the repo. The affected device is an AYN Odin Pro (SD845, Adreno 630), running PPSSPP v1.15.4 from the Play Store. The issue presents itself from the start of the game. Here is a save state made right after the first tutorial section, a particularly egregious point with aggressive culling: NPUZ00179_1.01_0.zip I can provide video footage or help troubleshooting if needed, although I am not familiar with the codebase, so I can only assist as an end user in this. |
|
I've added a workaround for this, the new Speedhack "Disable culling". This can be used to easily investigate these problems and confirm that this is the issue. Moving further work to the next version. |
Most of this is likely to be specific to hardware that can't use one of our various techniques to do clipping and culling properly with planes and geo shaders.
Previously we had
[DisableRangeCulling]in compat.ini (which isn't a good universal solution since some games rely on range culling).There's one issue in N.O.V.A on Samsung Galaxy A04E with PowerVR GE8320, reported by Ματchα and HeyImFranco on Discord:
020523_181715_001.mp4
This was previously worked around with DisableRangeCulling in #13989 .
GE dump:
NOVA range cull 17397 NPUZ00179.zip
Another issue seems to be Kidou Keisatsu Patlabor - see issue #17061
The text was updated successfully, but these errors were encountered: