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?