Pro Yakyu Spirits 2010 (NPJH50234): character shadows are not cleared properly per frame

[nassau-tk]

What happens?

Strange characters shadow appear.
But, May be it won't getting the dump corectly I think.
(It isn't understood by my knowledge.)
So,Please see attached screenshot & dump.

What should happen?

Graphic drawing corectly.

What hardware, operating system, and PPSSPP version? On desktop, GPU matters for graphical issues.

PPSSPP Ver.：1.10.3-581
OS：Android 9.0
DeviceName：SONY SO-02K / Xperia XZ1 Compact（Japan）
CPU：Snapdragon835（Octa-core）
GPU：Adreno 540
Resolution：720×1280
RAM：4GB
ROM：32GB
ExternalStrage：microSDXC 512GB

PPSSPP Ver.：1.10.3-581
OS：Windows10（64-bit）Japanese
CPU：Ryzen7 3800X（8-core）
GPU：RADEON RADEON RX5700XT
Resolution：2560×1440
RAM：32GB

[Before the issue happen.]

[After the issue happen.]

and

Dump files here.
NPJH50234_ProYakyuSpirits2010_Dump.zip

[Panderner]

@nassau-tk how is this look for software renderer and real hardware?

[nassau-tk]

@Panderner
Software rendering is not happen the strange shadow.

Is it meaning "Real Hardware" equal "Real PSP"?
If it's right.
Please,See below.[Real PSP ScreenShot animationGIF]

The dumpfiles isn't draw strange shadow isn't it?

[nassau-tk]

This strange shadow is cleared when switch the window to back ground on Android.
Cleared by switch to full screen on Windows(Not every time).
I can't get these strange shadow in GE Dump.
So,I attached MP4 file.
Please,See it.
NPJH50234_2020-09-19_05-20-45.zip

EDIT: D3D11 is not work.

[nassau-tk]

@hrydgard

This game is not working on "D3D11" at v1.10.3-711.
But, Working from v1.10.3-712.

v1.10.3-712-g7ed1ade56 | Henrik Rydgård | 2020-09-19 14:14:06
A couple of D3D11 fixes.

Just Report!!

But,This issue is still happen.

[nassau-tk]

And,This Baseball game has more seriese.

Pro Yakyu Spirits 2011 (NPJH50336).
Pro Yakyu Spirits 2012 (NPJH50520).
Pro Yakyu Spirits 2013 (NPJH50730).
Pro Yakyu Spirits 2014 (NPJH50838).

These games happen the same issue.

[hrydgard]

Thanks for detailed reporting!

ok so broken by 7ed1ade according to comment above - seems kinda weird...

[nassau-tk]

The issue still happen v1.10.3-1375.

[nassau-tk]

Re-tested on v1.10.3-1552 (Windows10/64-bit & Android)

I found a point.
If change to "Skip buffer effects(non-buffered, faster)" then shadow will draw correctly at [Vulkan/D3D9/D3D11].

[OpenGL] is still happen the issue on any settings.

EDIT: Pitcher's shadow will not correct drawing on all backends.

[unknownbrackets]

I'd guess something (possibly a reinterpret or memory transfer) should be clearing the buffer used for shadows.

-[Unknown]

[nassau-tk]

I got a log.
There is a few red code when timinmg of start up .

https://gist.github.com/nassau-tk/45c8f1aa599e3c48dcf536acb2cf7668

[unknownbrackets]

The original dump should look like this:

In playback, it does. This seems to be an issue with clearing previous shadows.

The lower shadow is drawn at step 41/275 from 0x0418e000. That buffer is rendered to at 67/275. To draw, it:

• Clears 128x128x16-bit at 0x0418e000 to 0x00000000 using a 5551 clear (color/alpha/stencil, not depth.)
• The clear has the 0x7F bits of stencil masked, but it's 5551 anyway so that should change nothing.
• Renders to 0x0418e000 as 5551 using 5551, flat, lighting color, and weights.
• During that render, it uses and ALWAYS stencil test to increment stencil.
• The render has color masked off and stencil 0x7F masked, so it writes stencil only.
• Once done, it does a stencil != 0 test to blend using fog I think. This causes the shadow.

When using that as a texture (back at 41), it sets it as a 5551 texture with blending based on src.a.

So that shadow (on the mound) should rely on simple stencil clearing.

The shadow for the pitcher is similar, but without a temporary (maybe because no mound deformation.) It:

• Draws shapes with everything but 0x80 masked off for stencil, but again it's 5551 so that just means write stencil.
• At draw 66, it unmasks color and does a full screen draw with a stencil != 0 test.

Interestingly, we begin the frame with a color-only clear, 5551. Then we do a alpha/stencil clear (separately...) with 0x7F masked for stencil. Then we do ANOTHER clear, this time stencil + depth but with stencil masked.

We seem to be handling the masking during stencil clears on 5551 incorrectly.

-[Unknown]

[hrydgard]

Interesting! Do we manage to actually convert it to a real clear in DrawEngine or is it drawn as triangles?

Our state mapping for stencil is rather complex so would not surprise me if we had a bug in either place...