Silent hill zero part of the body disappear

[daniel229]

Since #8467

[unknownbrackets]

So then, this is probably depth related. What happens if you put a return; at the top of BlitFramebufferDepth?

-[Unknown]

[daniel229]

return;at the top of BlitFramebufferDepth solves it

[unknownbrackets]

Okay, so then that probably means something else should be happening to depth, and isn't.

Since the w/h match, and z addr / stride match, my guess is that it's one of:

• Rendering on top of a framebuffer (e.g. targetting the framebuffer address and doing a clear.)
• CPU / block transfer (writing to the address of the framebuffer.)
• Flushing / flag issue (depth modified but flags not affected.)

For the last one, it's easy - find this:

if (!prevVfb->fbo || !vfb->fbo || !useBufferedRendering_ || !prevVfb->depthUpdated || isClearingDepth) {

And change to:

if (!prevVfb->fbo || !vfb->fbo || !useBufferedRendering_) {

If that helps, then we're missing some depth update flags.

For the first one, it's also easy, if you pause to menu and resume, the FBO creation - if it shows any FBOs that also use the depth address as being destroyed, then that is likely.

And for the second one, a breakpoint on the depth address (possibly also its mirrors) would do the trick. So if the z_address is 0x00088000, a memory breakpoint on: 0x04088000, 0x04288000, 0x04488000, and 0x04688000 each of size 0x00044000.

If it's clearing depth in a simple way, that's probably detectable and uploadable.

-[Unknown]

[daniel229]

That change also works.
There are 4 addresses for FBO reusing depthbuffer

18:11:651 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1934 Destroying FBO for 000d4000 : 1024 x 272 x 0
18:11:653 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1934 Destroying FBO for 0004c000 : 480 x 272 x 3
18:11:654 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1934 Destroying FBO for 00170000 : 480 x 272 x 3
18:11:655 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1934 Destroying FBO for 00020000 : 1024 x 64 x 0
18:11:655 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1934 Destroying FBO for 00000000 : 480 x 272 x 3
18:11:679 main         I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 000d4000 : 1024 x 272 x 0
18:11:682 main         I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 0004c000 : 128 x 128 x 3
18:11:684 main         I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 00020000 : 1024 x 64 x 0
18:11:684 main         W[SCEGE]: Common\FramebufferCommon.cpp:449 FBO reusing depthbuffer, 00020000/00000000 and 000d4000/00000000
18:11:685 main         I[SCEGE]: GLES\Framebuffer.cpp:620 Resizing FBO for 0004c000 : 256 x 256 x 0
18:11:686 main         I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 00170000 : 256 x 256 x 0
18:11:687 main         W[SCEGE]: Common\FramebufferCommon.cpp:449 FBO reusing depthbuffer, 00170000/00000000 and 000d4000/00000000
18:11:691 main         I[SCEGE]: GLES\Framebuffer.cpp:620 Resizing FBO for 0004c000 : 480 x 272 x 3
18:11:694 main         I[SCEGE]: GLES\Framebuffer.cpp:620 Resizing FBO for 00170000 : 512 x 256 x 3
18:11:699 main         I[SCEGE]: GLES\Framebuffer.cpp:620 Resizing FBO for 00170000 : 480 x 272 x 3
18:11:703 main         I[SCEGE]: Common\FramebufferCommon.cpp:412 Creating FBO for 00000000 : 480 x 272 x 3
18:11:793 idle0        I[SCEGE]: GLES\Framebuffer.cpp:1918 Decimating FBO for 00170000 (256 x 256 x 0), age 6
18:12:698 main         I[MODULE]: HLE\sceKernelModule.cpp:2109 sceKernelGetModuleId()

[daniel229]

only break at 0x04170000

[unknownbrackets]

Hmm, maybe it's because we're not copying the depth when it isn't rendered, but it's switching between three different buffers?

But also, Destroying FBO for 00000000 is a color buffer, and does indeed overlap with depth buffers: 00020000/00000000 and 000d4000/00000000 / 00170000/00000000 and 000d4000/00000000.

So all three of these are using 0x04000000 as the depth buffer, and there's ALSO a render target there. So many different sizes, though...

-[Unknown]

[daniel229]

But the way I found the demo.

demo and the savestate
https://drive.google.com/folderview?id=0BzGZGDfFE68zdXR6QVZNbGpkekE&usp=sharing

[unknownbrackets]

Hmm. At least some of this is using a == depth test. Anyway, There's also, it's switching depth buffers. The biggest issue is that it draws to framebuffer A, fills depth, and then draws to framebuffer B... and then draws to framebuffer C, expecting the depth to be there from A. But A and B have different depth buffers, so we don't copy.

This game does some crazy stuff also.

-[Unknown]

[daniel229]

This is also a regression after v1.1.1

[unknownbrackets]

Was this game ever really working well, though?

I think the issue in this game is that some, but not all, of the depth copies are happening. Before, possibly none were.

-[Unknown]

[hrydgard]

Does this still reproduce?

[RinMaru]

nope

[unknownbrackets]

Okay, so closing this based on that - but feel free to reopen/comment if I've misunderstood.

-[Unknown]

[daniel229]

Still happens in the latest build.

[CHNSK]

Flashlight works normally on Direct3D9, it's a bit slower for me but works.

[Ps3itaTeam]

If you turn off the flashlight, open/close the map and turn on again the flashlight, the issues disappear..

When indeed you leave the flashlight on and open/close the map the issues reappear..

[ghost]

Silent Hill Origin and Zero are the same?
I also experience this issue using ppsspp latest git build.

vulkan

opengl

[ghost]

Also on that part the fps is drastically drop

[ghost]

If you turn off the flashlight, open/close the map and turn on again the flashlight, the issues disappear..

When indeed you leave the flashlight on and open/close the map the issues reappear..

You are right 👍

Hope this issue will fix by this #14042 on OpenGL but how about Vulkan 🤔

[Panderner]

Hope this issue will fix by this #14042 on OpenGL but how about Vulkan 🤔

@Gamemulatorer Yes but Unfortunately that #14042 quoted:

Only works on desktop, this currently requires GL_ARB_depth_clamp which is not really supported on mobile (there is an extension, GL_EXT_depth_clamp, but few mobile devices support it).

This will not work on mobile but it only works on desktop.

[ghost]

I cannot find a temporary workaround for this game
so here's the updated ge dump.
Silent Hill Origin.zip

[ghost]

This is also finally fix 🎉

[ryzenvideous]

This is also finally fix 🎉

How, what, where, when, what do I do?!

[ghost]

How, what, where, when, what do I do?!

Use the latest build from https://buildbot.orphis.net/ppsspp/index.php?m=fulllist

[unknownbrackets]

See #6265. Since this was fixed around the same time, I'm going to close it. It seems clear they were both involving depth texturing of some kind and it was the same underlying issue.

If you're reading this and still experiencing the issue, it probably has to do with your GPU driver capabilities or may be a new bug. Please take a look at #6265 before creating a new issue or commenting.

-[Unknown]

[hrydgard]

This was still an issue for me as seen in #16126 in Origins, but with #16127, should be fixed.