ppsspp icon indicating copy to clipboard operation
ppsspp copied to clipboard

Sengoku Cannon - pink graphics problem on stage 2

Open Panderner opened this issue 6 years ago • 12 comments

The game works pretty well there a issue a pink thing appeared in stage 2

Panderner avatar Apr 14 '18 13:04 Panderner

screenshot_2018-04-14-21-39-52

Panderner avatar Apr 14 '18 13:04 Panderner

Are you using the latest git build? Does this happen with both Vulkan and OpenGL?

Could you try exporting a GE debugger dump on PC?

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

unknownbrackets avatar Apr 14 '18 15:04 unknownbrackets

still happens on 1.6

benderscruffy avatar May 27 '18 07:05 benderscruffy

v1.7.1-210-g9bda7cb64 still happens DUMP.ZIP

benderscruffy avatar Nov 28 '18 05:11 benderscruffy

v1.8.0-17-g737be61f9 still happens DUMP.ZIP

benderscruffy01 avatar Mar 23 '19 02:03 benderscruffy01

Still happens? All graphics backends or just some?

hrydgard avatar Aug 06 '19 22:08 hrydgard

Still happens on 1.9.2

Panderner avatar Sep 29 '19 04:09 Panderner

In the dump I picked, it looks like this is caused by draw 2/34. It looks the same as the correct PSP rendering if you skip that draw (below is the PSP rendering):

ULJM05021_#10914_sengoku_pink

The draw:

  • Depth clamp, viewport 32767 -32768, no minz/maxz
  • No texturing or frag color, verts are just normal/pos, both float
  • Cull: front (CW)
  • Fog: 19000 / 0.000053 f3dbbc (small impact on color of purple curtain)
  • Alpha blend: standard src.a / inverse src.a
  • Alpha test: a > 0
  • Depth test: src >= dst (framebuffer has all zero depth)
  • Actual color comes from lighting. Light 0 is enabled but does not really do anything. Curtain would be black without lighting, but still draw.
  • Material alpha is ff, but if it was 00 it'd ignore the draw.
  • Triangle strip, 34 verts. If it was 20, it'd be fine. If it was 21, you'd see less curtain.

If I force it to render from vaddr + 18 verts and limit to 3 verts, you still see the curtain. These are the verts:

X               Y               Z               NX              NY              NZ
56.827881	45.151855	-134.152344	0.000000	0.000000	1.000000
57.825562	1843.213379	-133.964844	0.000000	0.000000	1.000000
276.011719	166.368652	39.826172	0.000000	0.000000	1.000000

If depth clamp was off, this would not get drawn. What's confusing to me is that the X/Y/Z the GE debugger shows doesn't overlap the area you see the curtain in at all. It is at least CCW.

This happens in all backends, including software rendering. Maybe there's an interaction with cullmode and the clipping that depth clamp does... but I'm still confused why this shows up on the right side of the screen, when the max (transformed) X is 276.

-[Unknown]

unknownbrackets avatar Mar 09 '20 14:03 unknownbrackets

The rules noted in #12058 (speciifcally clipping) appear to fix this, at least in the software renderer.

-[Unknown]

unknownbrackets avatar Sep 08 '21 02:09 unknownbrackets

Software Rendering Screenshot_2021-10-15-08-34-50-305_org ppsspp ppssppgold v1.12.2-9

ghost avatar Oct 15 '21 00:10 ghost

Is that a slightly different frame? I suspect a particular precision issue, so it'd be good to get this right. I think it's related to clipping. Or is this wrong even with the original dump for your device?

It might be good to upload a couple frame dumps of different frames showing the fuschia / purple in different ways, to give more cases to test.

-[Unknown]

unknownbrackets avatar Oct 17 '21 04:10 unknownbrackets

Hardware Screenshot_2022-08-01-17-34-15-648_org ppsspp ppsspp

Software Screenshot_2022-08-01-17-35-19-968_org ppsspp ppsspp

ghost avatar Aug 01 '22 09:08 ghost

Frame dumps reproducing the remaining glitches in the software renderer would be helpful. The current one looks okay, so it's hard to know what's still off.

-[Unknown]

unknownbrackets avatar Oct 23 '22 07:10 unknownbrackets

ULJM05021_0003.zip here is a frame dump from software renderer

benderscruffy avatar Oct 29 '22 05:10 benderscruffy

Okay, so this actually seems to be another triangle inversion case, I think. See: https://github.com/hrydgard/ppsspp/issues/16207#issuecomment-1275553919, also #16131.

If I throw away all polygons that clip between negative and positive w, it looks good in that frame dump.

The PSP definitely doesn't throw all away, haven't figured out what the rule is yet.

-[Unknown]

unknownbrackets avatar Nov 14 '22 02:11 unknownbrackets

has been fixed with #16402
can be closed

benderscruffy avatar Nov 20 '22 10:11 benderscruffy

Isn't it still happening in the hardware renderer?

hrydgard avatar Nov 20 '22 10:11 hrydgard

I can still reproduce this using the dump. Screenshot_20221120_185948_2f85358b2198d26f8aca533d68bee793

ghost avatar Nov 20 '22 11:11 ghost

OK sorry just tried software renderer

benderscruffy avatar Nov 20 '22 11:11 benderscruffy

It feels like I would need geometry shaders or software transform to fix this for hardware, assuming the remaining cases are inversions...

-[Unknown]

unknownbrackets avatar Nov 20 '22 15:11 unknownbrackets