Closed MrCK1 closed 1 year ago
Forgot to add in the report that both dumps I captured in SW and HW have the playback issue. The dump that was uploaded was captured in the HW renderer.
I also got some more info from GSdx here that could be of use in the future. :)
Complex Alpha Test
Alternate ATE handling: ate_RGB_then_ZA
Additional tests on real hardware shows that the game uses pre-baked shadows at a distance and transitions to stencil shadows (I hope I got this right) when the player gets closer. I believe this is why the shadows are disappearing when the player gets too close in HW renderers.
Here's an in-game example
50/50 (Top half is pre-baked, bottom half is stencil shadow)
Full image
Transition layer (stencil shadow is missing):
Pre-baked shadow (photo was cropped, but taken further away)
Technically there is no stencil on GS.
Is SW renderer impacted (in game) ? Did you try zerogs ?
SW renderer is not impacted.
I haven't tried zerogs yet, but some tests a while back with older versions of GSdx around 0.9.6; and they didn't have working shadows in HW either.
If sw renderer is fine, it is likely a readback of GS memory by EE which is later transferred again to GS. I added some logs on readback and texture is dumped
@gregory38 So is there anything else I should get? I had no luck with captured frames from my graphics debugger, it doesn't get trace logs or anything unfortunately.
Enable gsdx hidden dump option. Do you see gl error in your debugger (which is btw)?
I use RenderDoc, it's cross-platform as well: https://renderdoc.org
"Enable API validation" is the option used in the program to get the GL debug logs, that's how I got the logs from Guitar Hero earlier. Unfortunately, this game doesn't print any GL debug, I don't get the individual drawcall frames either. It's a hit or miss depending on the game itself. In addition, I use GSdx-dbg when capturing.
I'll post example later frames later.
For some reason I can't edit my original comment, guess Github is glitching out.
Anyways, I got a successful frame capture after some tinkering. For some reason, the missing alpha textures are positioned in an odd orientation. As for debug messages, here are the Medium severity ones:
All gl messages are stored in a debug file (should be current dir). It will greatly help you to understand what happen. Debug build is quite verbose because you have all TC information.
The above message is about a texture depth effect. Typically the green channel of depth buffer (bit 8-16) are copyied into the alpha channel of a color buffer. Hint if the detection of the effect doesn't work, it is wrongly replaced by a FBMSK emulation. If you spot those message, there are likely a bug.
You need to check the code of InvalidateLocalMem. This function will transfer code from the GPU to the GS mem which could be send to EE. Check the code there are some GL related messages.
Here's the log: SmugglersRun_opengl_debug_hw.txt
2nd Log: GSdx_opengl_debug_hw.txt
Log analysis. There is a color effect based on channels shuffle (from ba to rg). Around draw call 13. The source is located at 0x1180 and the destination is located at 0x1200. My feeling is that we have some kind of overlapping of color buffers/textures.
Edit: next step, to confirm the behavior, is to get the resolution of the color buffer. The width can be extrapolated from FBW register value (...._context.txt
file) i.e. width = 64 * FBW
. Above address 0x1180/0x1200 are in block unit.
@gregory38
Here's the context for drawcall 13. If you need 14, ect. let me know ;)
FRAME
FBP (*32):0x1200
FBW:16
PSM:0x2
FBMSK:0x0
New GS Dump: smugglersrun_badtex.zip
This is the raw dump with all the drawcalls, contexts, ect. smugglersrun_debug_contexts.zip
Analysis main issue is about a texture channel implementation. Input: 0x0/0x1180 Output: 0x80/0x1200 Effect: permutation of RG and BA channels
Tricks are
Permutation is easy to implement. But overlap/pixel positions will be tricky.
I'm not sure the game rely on overlapping. So I propose that we implement an hle dedicated shader to implement color channel shuffles. I'm afraid that shadow position will require the pixels position update too. But we will see if at least some shadows appear.
HW Shadows are also missing in TLoS 2, just thought I'd mention that here, seeing that both games seem to suffer from the same issue.
PCSX2 version: v1.5.0-dev-2104-g49840bb
PCSX2 options: Defaults, Safest
Plugins used: Defaults. Both GSdx plugins used in the emulator and GSDumpGUI are matching versions
Description of the issue: In Smuggler's Run, shadows near the player have never been rendered in any HW renderer. In addition to this however, the GS Dump shows an outline of the shadow in HW mode, where they were missing in-game. In all instances, distant shadows are still rendered normally.
How to reproduce the issue: In-game: Boot game, drive to an area with shadows.
GSDump: Select any HW renderer, find first frame and observe shadows. As a side note, you can see the alpha texture of the trees shadows flicker at the top when stepping to another frame in the GSDump.
GSDump SmugglersRun_ShadowsHW.zip
Last known version to work: Never
PC specifications: Intel Core i5-6600k, GTX 1070, Windows 10 Home 64-bit
In-Game (HW):![gsdx_20170530132642](https://cloud.githubusercontent.com/assets/16314399/26597571/67b2840c-4540-11e7-952f-ac7c2ceb9920.png)
GSDump (HW):![gsdump](https://cloud.githubusercontent.com/assets/16314399/26597618/93a0db0e-4540-11e7-9187-e0eebd37a538.png)