-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ghost In The Shell - Stand Alone Complex (ULUS10020) - Black Textures and missing screens. #12519
Comments
Have you tried every backends? |
Yes. There's no difference between opengl, vulkan or direct3d. Tried several other graphical settings, but none of them makes a difference. |
Thanks, good report! Especially tracking down the change responsible. This should just be a matter of handling bad fog parameters a bit differently. Could you get a GE capture of the situation for easy investigation? https://github.com/hrydgard/ppsspp/wiki/How-to-create-a-frame-dump |
Here is the dump file: |
The game render with:
Vertex shader does this and get a negative number:
Fragment shader then clamp to 0 and just render the fog color (black):
Frame dump (I hope is dumped correctly): Set both fog coef to same sign make it render fine. |
Ok, nice debugging! Not quite sure if the game is intending to do something special with those settings or if it's just a game bug that happens to work on the hardware.. so exactly what the correct fix here is I'm not sure.. |
Here there is a gameplay on read HW (https://youtu.be/TDlABQogoqw?t=240): It seem pretty the same as with no fog. |
Hm. So the PSP game itself is using: Fog End = INF When I use those same parameters in a simple test, I also get black. What's more, when I run that dump on a PSP, I get... Compare to our rendering (softgpu): I wonder if the actual problem is somewhere else, where it's calculating these values to even send to the display list. -[Unknown] |
If you run this game using software rendering (try to use an ingame save if possible), does it render properly? If yes, it'd really help to have a GE dump while running software rendering too. -[Unknown] |
Here a dump from 1.9.4 Software rendering, same problem (uploading the dump anyway recording.ppdmp.zip) This game seem to segfault (on linux at least) at start on master, will bisect later for the right commit. EDIT: 54e1afd is the first bad commit, guess was expected to be this one. |
@iota97 do you see anything interesting in the log console? |
Mhhh, I still get the black model on my desktop (while is fine on android for me as well), the dump render fine on my desktop as well. As the previous dump had weird value on the uniform was likely a bug on the CPU side before it get to render, still was is kinda weird is that desktop is broken with every CPU backend (JIT, IR, Interpreter), but Android is fine with all of them. I wonder how it work on desktop ARM like a raspberry TBH, haven't got any to try tho'. PS: phone is Redmi 4X (Qualcomm Snapdragon 435 MSM8940), desktop is Linux x86_64 (intel i5-6400). |
@iota97 have you tried every backends? |
Both Vulkan and OpenGL produce the same result, DirectX is not available on Linux so that was not tested, but I doubt GPU backend matter tbh. |
Are you using Linux? |
u_fogcoef.y is 65535.0f on the android dump, may ARM just produce a +NaN rather than a negative one somewhere making it display ok... |
Right, this is either a CPU bug, or some sort of timing bug where some game is not (or is) being executed to fill in some state. It's probably not ideal that some Android phones are (incorrectly) rendering this as non-black, because we're currently telling them to. So that's actually a separate bug. We should not try to make that bug exist on Android too, because we know that's the wrong behavior. -[Unknown] |
I don't really get why you say it's incorrect to render them non-black, on android the uniform are different (the android dump render fine on desktop too), doesn't this mean that some value sent to the PSP GPU by the game end up being computed different? The real PSP render it black with the desktop value as well, while they might be 2 bug cancelling them couldn't also be android being closer to correct? |
Oh, I thought it was just that the Android device GPU was interpreting differently. If a dump created on Android renders correctly everywhere else, that points to a likely jit bug. Sorry for misunderstanding. The web debugger can connect to Android: http://ppsspp-debugger.unknownbrackets.org/ I don't have the game, but if you use a data breakpoint to see where it's writing to the fog values in the display list, you can trace it back to where it's generating those values. The trick will be to find where it's calculated differently. -[Unknown] |
Just to note that it's always broken on desktop and always work on android with all the 3 CPU backend (JIT, IR, interpreter). About the breakpoint how am I suppose to know where is writing in the display list in first place? Also I can get only the +/-65535.0f from RenderDoc on Linux, anyway to get the exact value the game is passing? I doubt I will be able to find anything in that debugger myself sadly :/ |
Well, I still haven't gotten around to adding the GE debugger to the web debugger (it's technically possible and not all that hard, I should get back to it...) If you use WINE and run the Windows version, you can use the GE debugger. In some ways, it's like RenderDoc, but it shows you exactly what the game is sending rather than what we translated that to. It also lets you step through the GE display list and set breakpoints on GE registers (such as fog.) Warning: I've heard the debugger looks kinda not great in WINE without MS fonts. Once you have the GE debugger up:
From there it's just tracing backwards. If it's "hard mode", here's how to deal with save states:
-[Unknown] |
After this f0 result in +NaN on android but -NaN on desktop. Tested a C++ program on x86_64 making that multiplication and result in -NaN indeed (NaN sign is meaningless so I guess is up to the CPU/Architecture what to do?). If you could test this float operation on the real PSP would be useful I guess, also would be nice to know if -NaN is ever a thing on the PSP FPU (changing the display list conversion to +65535.0f for any NaN might be a workaround in this case). |
Negative NaN is a thing on the PSP, but mostly with the VFPU (and unfortunately, isn't even meaningless there.) Will test this in a bit. -[Unknown] |
Yep, it's definitely supposed to be +NAN:
(the - results are PSP, + are PPSSPP on x86.) It is correct on ARM for me too, but I'm not sure if it's guaranteed: (Snapdragon 821)
-[Unknown] |
See hrydgard#12519 - this is needed for some graphics to render properly. Seems to already happen on ARM, so no change to armjit.
See hrydgard#12519 - this is needed for some graphics to render properly. Seems to already happen on ARM, so no change to armjit.
What happens?
Some textures are black and some screens are completely missing (also black screen). The missing screens includes the green text intro at the beginning and chapters names. It's happening since 1.6.3-454. It seems #11380 broke it.
What should happen?
The proper image should be as follows:
What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.
It happens on any version after 1.6.3-454.
Windows 7 64-bit, GTX 750 ti, 8gb RAM.
The text was updated successfully, but these errors were encountered: