Star Ocean First Departure

[fivefeet8]

What happens?
Characters hidden behind objects.
What should happen?
They should be seen on top of them.

What hardware and operating system are you running PPSSPP on? GPU might matter if it's a graphical issue.
Using opengl on Snapdragon 820 ZTE Axon 7

[fivefeet8]

Vulkan render does the opposite. Characters are rendered in front of objects they should be behind.

[unknownbrackets]

Are you using the latest git build? What render resolution?

-[Unknown]

[fivefeet8]

Latest build at 4x resolution.

[unknownbrackets]

Interesting, happens at 1x too.

OpenGL: Seems like it's somehow only doing the bottom right quadrant of the screen. Maybe scissor is still set, but I wonder why it behaves differently on desktop.

Vulkan: Maybe it's not even uploading stencil at all, for some reason. Could even be a driver bug.

-[Unknown]

[fivefeet8]

Confirmed that the rendering errors don't happen on my Shield Tv on either renders.

[ppmeis]

Tested on latest Windows build. Even using 10x IR and texture scaling under Vulkan all seems to be fine:

Under OpenGL, if I use any texture scaling (xBR, Hybrid, etc) there are a lot of issues:

Without scaling, OpenGL looks fine:

[fivefeet8]

Still the same no the latest builds.

[unknownbrackets]

Vulkan on Adreno is apparently misdetecting the shader as one that's safe to run early fragment tests on. At least, discard; in the shader as no effect. Changing the coords in the vertex shader does.

Writing statically to gl_FragDepth causes it to work properly, but the spec says that OpKill should disable early fragment tests (unless explicitly enabled.)

Maybe GLES has the same issue... checking.

-[Unknown]

[unknownbrackets]

So on GLES, this makes it work:

static const char stencil_vs[] = R"(#version 300 es
precision highp float;
out vec2 v_texcoord0;
void main() {
	int id = gl_VertexID;
	v_texcoord0.x = (id == 2) ? 2.0 : 0.0;
	v_texcoord0.y = (id == 1) ? 2.0 : 0.0;
	gl_Position = vec4(v_texcoord0 * vec2(2.0, 2.0) + vec2(-1.0, -1.0), 0.0, 1.0);
}
)";

That works fine with the fs, with appropriate #version. The original vs for reference:

#ifdef GL_ES
precision highp float;
#endif
#if __VERSION__ >= 130
#define attribute in
#define varying out
#endif

attribute vec4 a_position;
attribute vec2 a_texcoord0;
varying vec2 v_texcoord0;

void main() {
  v_texcoord0 = a_texcoord0;
  gl_Position = a_position;
}

I triple checked the verts being passed in, which seem fine. We could in theory just use a different shader on GLES3, if this is a driver bug. Ignoring the attributes doesn't seem like a problem, per se. But I don't get how they're going wrong.

-[Unknown]

[unknownbrackets]

Arrrggg, no, it's missing the semantics.

-[Unknown]