hrydgard
commented
1 year ago Next we have a more complicated scene. This one, in the hospital, has a funny glitch where a smaller depth buffer interferes with the main one, causing this problem where the ladder from the bottom-right of the screen clips the character:
This glitch is a bit ephemeral though - it disappears if you save/load state, for example. That means that somewhere along the way, the combined actions we do (resizing framebufffers etc) don't come out the same way as if you just start over. You can get it to happen again by leaving the room into the elevator and coming back.
In this frame, the game does a lot of stuff early in the frame too that looks like it's rendering a depth map from the position of a flashlight. This has been previously discussed and is a separate issue that also needs solving... Let's see if we get there.
More investigation to come.
ghost
unknownbrackets
inukaze
CLPSAW
This is likely gonna be a long one, which is why I'm starting a brand new thread.
There are multiple things going wrong with the graphics of the two Silent Hill games. Going to start with Silent Hill Origins and work my way through it over time. During the investigation I will get it working on Vulkan first.
A first note is that we end up creating framebuffers of size 1024x64. This might be fine, but they shouldn't work to texture from, at least not in their entirety (max is 512), so we'll see what happens with those.
Another little side note is that if you choose any brightness setting above 0, the game adds an additional CLUT rendering pass, that grabs one color channel of the frame, applies an inverted grayscale gradient and adds that to the frame, boosting the dark colors. To make things as simple as possible I will not turn that on, plus, it seems to work correctly already.
A third side note is that due to another issue I was running with vertex cache enabled, and hit a VK validation check when the vertex cache grew. That push buffer is shared across multiple frames, but our queueing destruction of the old one should have worked to prevent any kind of problem here? I'm a bit confused.
A fourth note is that there are two main frame structures - one in the intro and burning house scene for example, which includes a bloom effect, and one for dark indoors scenes like some rooms in the hospital, where the flashlight is available. In those, no bloom is there but a super advanced shadow mapping effect is, which isn't working correctly. I guess bloom + shadows are too expensive together.
Anyway, the intro of the game, running along the road, then trying to rescue the girl in the burning house, seems to work correctly, or at least, any rendering errors are not yet visible.
We're gonna investigate some different scenes, since the game seems to switch up its rendering quite bit.
Frame structure, burning house (things look mostly correct here, but as we shall see, not completely)
The framebuffer setup is quite unorthodox. Note: In framebuffer addresses, I'll often omit the "04" prefix.
This initial walkthrough is done through RenderDoc since it's faster to see what's going on, but it's possible to miss things. Next I'll go through again using PPSSPP's GE debugger, now that I understand the structure of the frame.
d4000 seems to both be used as a double-wide 565 target, and a 8888 target, at different points in the frame - though I won't pretend I understand what's going on with that yet. Anyway, the frame starts by clearing half of it to black, as a 565. Which half seems to alternate per frame.
Then, we draw a weird little shape to a 128x128 target at 4c000. Our buffer there is much bigger for some reason.
Then we switch to a giant 1024x64 target, and blit the 128x128 image to the very far right side:
Back to d4000/00000, where we now treat it as a 480x272 8888 with Z at 00000, and render the scene to it, including the main character. This looks completely normal - well, it's pretty bad at culling so it draws a lot of out-of-viewport stuff, but doesn't matter. We end up with:
Next, we render the scene one more time, this time to 0170000, again 480x272 8888 with Z at 1c000. But we render almost entirely black, except smoke at the end, and at slightly more than half resolution, 256x160, probably we misdetected the render target size:
Back to d4000 again, where we render some fire effects:
At the end, we try to render the previous smoky target on top, but it has a very subtle effect:
Next, there's a weird draw that textures from the top right pixel of 170000 and draws it to just outside the top right of 00000 treated as 8888 color this time (remember, depth was here before). No idea what that's about. We don't inject a reinterpret here because we regard 8888 and depth as incompatible for that purpose.
Moving on, we're at 170000 (the smoke). We first draw some black into the image, looks like we're clearing borders for the upcoming bloom effect stuff:
We now take the previous scene image from d4000 and copy it to the top left quarter, while boosting its brightness:
Next follows a typical bloom effect where we bounce the image around itself (which causes PPSSPP to do a lot of image copies), will skip most of the steps but here's one:
The bloom is then drawn on top of the image, plus some noise and a weird invisible horizontal bar:
And we're done.
Though there's some weirdness with the final blit! The image we end up blitting to the display is the other half of the d4000 565 image, from the last frame I guess? So there's a frame of latency? Still haven't figured out how the last frame ends up in place...
So far so good. I think we're mostly OK here actually though there's some weirdness. Next up, a scene that actually breaks. Soon!