Sengoku Cannon - pink graphics problem on stage 2

[Panderner]

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

[Panderner]

[unknownbrackets]

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]

[benderscruffy01]

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

[hrydgard]

Still happens? All graphics backends or just some?

[Panderner]

Still happens on 1.9.2

[unknownbrackets]

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):

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]

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

-[Unknown]

[ghost]

Software Rendering

v1.12.2-9

[unknownbrackets]

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]

[ghost]

Hardware

Software

[unknownbrackets]

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]

Okay, so this actually seems to be another triangle inversion case, I think. See: #16207 (comment), 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]

[hrydgard]

Isn't it still happening in the hardware renderer?

[ghost]

I can still reproduce this using the dump.

[unknownbrackets]

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

-[Unknown]