Hunter x Hunter: Wonder Adventure missing shadows

[benderscruffy]

Game or games this happens in

Hunter x Hunter: Wonder Adventure NPJH50624

What area of the game / PPSSPP

during gameplay missing shadows

here is a GE dump
NPJH50624.zip

What should happen

shadows should be present
this is how it should look

Logs

No response

Platform

Windows

Mobile phone model or graphics card

AMD RX 580

PPSSPP version affected

PPSSPP v1.13.1-234-g5434bd83e

Last working version

No response

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 without any cheats and without loading any save states.
• Include logs or screenshots of issue.

[hrydgard]

Had a cursory look. Some notes:

At step 2900 the following curious CLUT setup is used while reading a 64x64 texture:

Which is, use a CLUT32 format, and extract the alpha channel and use that to do a lookup with its bottom bits (mask 0x1f) into a palette. The CLUT has a weird choppy alpha/gray gradient. Unlike my first instinct told me, stencil tricks do not seem to be involved here though, if there are tricks, it's how they fill alpha.

And indeed, right before drawing the shadow, at step 2761, it draws stuff to the top left 64x64 of the main framebuffer, drawing a hidden image which is the shadow, into the alpha bits, using alpha bit masking (a PSP-specific feature):

Note that e0 is the inverse mask of 1f, which matches the depal setup.

We do have a compat feature to (slowly) simulate bitmasking, let's see if it helps... Nope, doesn't work, the draw gets killed by the stencil test. Which I'm not sure is actually configured correctly for this...

Through out the shadow rendering, including a first quad which wipes the corner of the image, it seems to use the following stencil test:

But it uses clear mode during that first quad. So maybe the ref bits just are supposed to get written, in which case the rest should succeed.. hm. Back to renderdoc

Yeah, during the stencil clear we are erroneously applying the mask:

bug!

Shouldn't be too hard to fix, will do it soon.

(misinterpreted things, it seems)

[unknownbrackets]

The stencil test is not supposed to be applied in clear. However, the stencil/alpha write mask is supposed to be applied, always. That is not an error.

Does this work in software rendering (which correctly does apply the pixel write mask to clears)?

-[Unknown]

[unknownbrackets]

Looking at the dump, it does work in software rendering. The first draw to 64x64 is 2761/2926 in this frame dump.

At this point (in softgpu), the stencil values are zero before the clear, so it doesn't actually do anything or matter. Vulkan seems to be the same.

At 2900 in Vulkan, I see stencil values in the buffer but the alpha value is still zero. Then we sample from alpha. But that's without the shader bitmask.

-[Unknown]

[hrydgard]

Hm, right. There's at least some weird interaction between the alpha mask and the stencil test that we don't get right ... and the reason the ref value is 0 during the clear (setting the stencil value to that) is that software transform of the clear sets result->setStencil to the color value of a corner. The vertex indeed contains a 0 alpha value so that seems right, but it seems to me to preclude the rest of the shadow rendering from doing anything.

The software renderer does render the shadow correctly.

I'm using this compat.ini setting to enable shader bitmask emulation:

[ShaderColorBitmask]
NPJH50624 = true

I'm moving on from this for today (will get back to it at some point of course), but feel free to have a look if you like a little stencil mystery.

EDIT: looks like you beat me to this post, oh well

[hrydgard]

The shader bitmasking emulation does seem to want to set the right bits into the alpha channel, I think, but the EQUAL stencil test fails the draw so it doesn't happen.

[unknownbrackets]

Looked at this again in RenderDoc, the issue is that stencil is an EQUAL test, but it fails (as you said.) So it still REPLACEs the stencil value, but no alpha value is written because stencil failed. As long as RGB is fully masked, it should be safe to force the stencil to ALWAYS.

-[Unknown]

[hrydgard]

Please test again on a build where #15822 is merged, should work. Thanks @unknownbrackets ! Tricky stuff due to the stencil/alpha conflation.