Zettai zetsumei toshi 3 fire and smoke

[IrfanH495]

Game or games this happens in

ULJS00191 - 絶体絶命都市３ ─壊れゆく街と彼女の歌─

What area of the game

Zettai zetsumei toshi 3 fire and smoke
Vulkan

Opengl

save data before running from falling car.
SAVEDATA.zip

What happens

save data before running from falling car.
SAVEDATA.zip

What should happen

ver 1.13.2 playstore

GE frame capture

No response

Platform

Android

Mobile phone model or graphics card

Samsung m20

PPSSPP version affected

ppsspp-v1.13.2-1509-ge179e466e-android

Last working version

No response

Graphics backend (3D API)

OpenGL / GLES

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 changing graphics settings to determine if one causes the glitch (especially speed hacks or enhancements/replacements.)
• Include logs or screenshots of issue.

[IrfanH495]

ULJS00191 GE dump.zip

[unknownbrackets]

That frame dump should look like this:

Software has an interesting glitch, and some lighting that's off:

That happens on draw 787/2185, which according to the vertex preview at least - shouldn't even touch those pixels. Skipping that draw fixes it. So something is wrong there - maybe some failure in clipping or vertex cull?

Depth clamp is enabled, and there's only 5 verts - Z is being clipped. These are the two triangles of that which visually cause the problem:

Tri 787/3:
screenpos: 241,233 - 9469,3966 - 3469,3966
     orig: 241,233 - 779,263 - -31,-82
  clippos: 0.146357,-24.275625,31.974953,33.958847 - 60.283821,-25.117168,24.841423,26.828796 - 21.537600,-30.528482,-21.028488,-19.018715
  clipped: 0.146357,-24.275625,31.974953,33.958847 - 38.455627,-28.165703,-0.999996,0.999996 - 13.454458,-28.165705,-0.999997,0.999996
           dp0: 65.933800, dp1: 51.670219, dp2: -40.047203 (new 65.933800/0.000000/-0.000001)

Tri 787/4:
screenpos: -1113,3966 - 241,233 - 3469,3966
     orig: -31,-82 - 372,-128 - 241,233
  clippos: 21.537600,-30.528482,-21.028488,-19.018715 - -8.531132,-30.107710,-17.461723,-15.453690 - 0.146357,-24.275625,31.974953,33.958847
  clipped: -5.641649,-28.165707,-0.999998,0.999998 - 0.146357,-24.275625,31.974953,33.958847 - 13.454458,-28.165705,-0.999997,0.999996
           dp0: -40.047203, dp1: -32.915413, dp2: 65.933800 (new 0.000000/65.933800/-0.000001)

Oh, clipping maths again. Joy. Focusing on the first one, it created the bluish triangle trying to clip the red one:

It seems like the points are counter-clockwise here. Maybe we need to cull before clipping. That seems sensible? Anyway, that's not the original issue, just interesting and related. I'll look at the hardware rendering after this.

-[Unknown]

[unknownbrackets]

GLES/D3D11/D3D9 all look like this in that frame dump, for me:

Vulkan is the most exciting, as it has broken and missing chunks but looks similar otherwise:

Fires happen at 1892/2185, with src.a / inverse double dst.a factors, which probably convinces us to use an input attachment. Probably that's not working properly in Vulkan. It seems pointless though, because dst.a is entirely zero. Sigh. It literally never uses stencil testing without KEEP/KEEP/KEEP, at least in this frame.

At this point, pre-smoke (much less bright fires than they should be so far):

Smoke is at 1907/2185, which uses dst.a / inverse double src.a - a bit more interesting. Since dst.a is 0, the incoming color is ignored. But the smoke texture has useful src.a, from 0-255 (in fact it's otherwise all white.) So this essentially darkens the screen by the alpha: dst = dst - dst * 2.0 * src.a This makes sense for a smoke effect.

But... for some reason there IS alpha in OpenGL, for example. This makes both effects different than on software. 1899/2185 for example adds some alpha. Blend state is disabled and alpha not masked... but stencil test disabled. Probably related to the fragment read.

-[Unknown]

[IrfanH495]

thank you, I've tried ppsspp-v1.13.2-1517-g61e7c3e62 everything looks fine to me.
Opengl

vulkan

[hrydgard]

I guess we can close then?

[unknownbrackets]

Just some notes for later on the software renderer issue:

I simplified the vertex down to this (depth clamp must be enabled):

	VertexF32 verts[5] = {
		{ 1.5f, 1.5f, 2.0f },
		{ 1.0f, 1.5f, 1.0f },
		{ 1.5f, 1.5f, 0.0f },
	};

And with this projection matrix:

	ScePspFMatrix4 viewproj = {
		{  4.0f,   4.0f,   24.0f,   24.0f},
		{  0.0f,   0.0f,    0.0f,    0.0f},
		{  8.0f,  -1.0f,   -1.0f,   -1.0f},
		{ -8.0f,  -8.0f,  -28.0f,  -28.0f},
	};

The PSP doesn't draw anything. Higher values of the the wz factor (-28.0, so -27 and so forth) are similarly not drawn.

However, -29.0 and -30.0 are drawn (and it's an inverted polygon.) It's happenstance (maybe) that wz and ww match, because -28.5 for wz doesn't draw and -28.6 does draw.

Additionally, as far as I can tell:

• Culling based on wind order before clipping did cause rendering glitches.
• Negative W is not clipped as best I can tell, unless all verts are negative W.
• As noted, the PSP does clip in a way that allows inverted polygons to occur.

Haven't really worked out what the rule is that should cull this drawing.

I did also create a reduced frame dump to make it easier to verify:
#16207_ULJS00191_disaster3_smoke_edit2.zip

This should render nothing, but:

• In software, it renders multiple triangles which are incorrect.
• In hardware (GLES/Vulkan/D3D9/D3D11) it renders one triangle which shouldn't be rendered (but visually looks okay, so it ends up fine.)

-[Unknown]