ppsspp
ppsspp copied to clipboard
hrydgard
Ratchet & Clank - Light bleeding through walls
Is this with hardware transform on, off, or both?
https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger
-[Unknown]
I wouldn't be surprised if it's a depth issue, we still have multiple games with depth issues.
Did it ever work in a previous version? If yes, what's the first build that stopped working, and the last build that did work?
Yes, definitely could be depth. Not clear on how it's drawing those lights...
-[Unknown]
this is a depth issue (?)
Things still bleed through the walls like sprites and the waterfall in the first level
I have the same issue as well on both v1.1.1 and the latest Git build. Here is a screenshot:
Yes, we know this is still an issue.
So far, depth is just a guess. I don't have the game, but what probably needs to happen is someone needs to walk through a frame, and see what it's drawing. For example, does it do anything with depth that looks interesting before drawing the lights? Does it seem like the lights ought not be drawn?
Also, it could be worthwhile to set a breakpoint where it has its depth buffer, to see if it's manually clearing it to some value or something at some point.
Want to give it a shot?
-[Unknown]
@unknownbrackets Sure, I am somewhat unfamiliar with PPSSPP's debugging features because I haven't run into any issues besides this, but I will do my best.
Is there a good place to start?
The GE debugger really really really helps. It's Windows only, so if you're not on Windows, I suggest WINE. It works pretty well per my last test, although it helps a lot to have Windows fonts. The first thing I usually do is click "step tex" to get a mindset for how the game is rendering the frame, and at what point it draws the problem thing.
So, I would look to see when it draws these things, what under the "Flags" tab it's using to draw. Many of these are tests - depth test, alpha test, etc. Note that @LasagnaPie's screenshot above implies that it's rendering these things to a temporary buffer - so how it initializes / clears this temporary buffer is likely important too.
Then look to see where it's rendering this temporary buffer (if my assumption is correct) to the screen. This may also use tests, such as alpha, stencil, or etc.
It's likely that one of these tests should be preventing the thing from drawing. You can double click a test to disable it, and under "Settings" you can change the test parameters.
There are a lot of areas where things get complicated (stencil and alpha are the same bits on a PSP, for example.) I think if we first establish what it's even trying to do, we'll be in a good starting place.
-[Unknown]
@unknownbrackets I am on Windows, and I just opened the GE debugger. I am really impressed with how easy it is and how friggin' useful this can be!
Anyway, the waterfall and the smoke/steam that is clipping through everything are rendered separately.
The texture (or I guess maybe it isn't really a texture, it's hard to explain) in question is Texture L0: 0x04154000 (64x64). It seems to be rendering the alpha transparency of the smoke or steam or whatever it is.
Here are the flags:
Lighting enable 0 Light 0 enable 0 Light 1 enable 0 Light 2 enable 0 Light 3 enable 0 Clip enable 1 Cullface enable 0 Texture map enable 1 Fog enable 0 Dither enable 0 Alpha blend enable 1 Alpha test enable 0 Depth test enable 0 Stencil test enable 0 Antialias enable 0 Patch cull enable 0 Color test enable 0 Logic op enable 0 Depth write disable 0
I can give you any of the other information if it helps.
It renders the waterfall steam nearly last of every frame, and it seems like it does the rendering in multiple texture files or maybe multiple rendering passes or something. It renders black backgrounds with the steam as white, which I assume means those are the transparency layers, but it does this a few times, so I'm not sure. It never appears rendered in-game, only in the Step Tex box with the GE Debugger in use, where all the alpha transparency stuff is happening.
I hope I gave you an accurate explanation. :laughing:
I took 3D animation and 3D modelling and stuff, but I am somewhat pressed to exactly define what is going on.
Heh, yeah, we built it because we were looking for a way to see rendering. It's not all that different from frame-recorder style debuggers like you have for OpenGL, except it focuses on showing what's happening.
Okay, what you might try now is see if you can savestate the problem scene, and then load it using the software renderer (last setting in graphics, have to quit the game first.) The software renderer still has glitches, and is very slow, but it serves as a reference implementation - and it supports most of the nasty things a game could do very well.
If it renders correctly in the software renderer, the good news is the GE debugger works for the software renderer too. You can go to where it tries to render the 00154000 framebuffer, and make sure it's supposed to draw it completely, and then see how the texture gets rendered.
Assuming that it's supposed to draw the entire thing in the 00154000 buffer as shown here: https://cloud.githubusercontent.com/assets/7449866/3018291/ee0ae75e-df83-11e3-91ad-796b0e396c25.jpg
Then likely this is some stencil vs alpha issue, since the only useful flag enabled above in your post is alpha blending. What blending mode is it using (seen under settings)?
-[Unknown]
@unknownbrackets Well, I have bad news. The software renderer doesn't render it correctly either. :cry:
So what should I do now?
I mean, it exhibits the same behavior as with the hardware renderer...
Huh, I would have guessed that the game was just doing unsynchronized reads from the depth buffer, which should be enough to occlude glow sprites "good enough", but the waterfall surface blending confirms to me that that's not it, and it indeed is some render state thing ... Very strange.
This seems to be related to some issues in Secret Agent Clank, if I remember correctly. Let me fire up that game and see if I can find the issue in that...
Unless it's reading from a mirror of the depth buffer manually, and expecting to get correct values? Or something?
You can try, in the Dissasembly window, click Breakpoint. Then set a breakpoint on 0x04200000 with size = 0x00600000. And then just run the game. It'll pause emulation if that breakpoint ever hits, which means something on the CPU is trying to access a VRAM mirror, which usually means shenanigans.
If that doesn't hit either... hmm. Might see if there's ever access to the 0x04154000 area, size = 0x4000. That's the 64x64 texture you pointed out. But, it's probably not that, since that ought to work in the softgpu.
It also can't be minz/maxz, since that's also implemented in softgpu. Hmm.
-[Unknown]
I don't see how they could possibly get the waterfall surface to render nicely by reacting to depth buffer reads, while for the glow sprites, a single point read that would stop a sprite from getting rendered would look quite good. So like I said I highly doubt that's it...
@unknownbrackets @hrydgard Well, 0x04200000 was a no go. Let me try 0x04154000...
Actually, 0x04154000 didn't hit either? Now I'm really confused...
I found the demo. demo and savestate.Have to set FuncReplacements = False first,otherwise it hangs. https://drive.google.com/folderview?id=0BzGZGDfFE68zWHp6d1laczliclU&usp=sharing
Bars on door: 0x0994ab40, door itself: 0x09920000
Door is drawn with minz=15, maxz=65520, which I now recognize as a technique to clip. Scale is 32768 +- 32752, which matches the minz/maxz. The depth ends up around 8000-9000.
The source of the waterfall is 0x099ed080, which is drawn to a temp buffer at 0x00154000.
It draws this to screen using:
- Flat depth.
- No tests.
- Alpha blending (fixed 000000 + src * dst)
- A tweaked minz/maxz that looks like it might clip the flat depth, except it's throughmode which ignores minz/maxz.
It then draws it another time, and this time seems wrong. It uses src.a as the blend, but src.a is 0.... however it's an 565 texture. The vertices have no colors and lighting is off... but the material alpha is 0xff.
Even if I kill the alpha, there's weird black clouds there. Hmm...
-[Unknown]
This game is drawing to 0416b000, which it then reuses as a depth buffer. And it is indeed using a mirror. Not sure how I missed this before (I think I was just checking for CPU reads.)
Basically:
- It uses texturing to stretch 04710000 (480x276) -> 0x04154000 (160x92) as 565.
- It then copies that from 04154000 (previously, and after, used as a color buffer) to 0416b000, again 565.
- Next it uses 0416b000 as a depth buffer, doing depth tests for drawing to the temporary 04154000.
- Once it's drawn the depth-tested effects to the temporary, it simply blends them to the screen.
That it's using a temporary in between (04154000) makes this even harder to simulate - a direct copy to a depth buffer would be easier to detect. But it's also a problem that it's stretching it, not directly blitting it. Luckily it is just nearest.
Notably, software is kinda working now. When the waterfall is correctly visible, objects near it are getting a weird z fighting or swizzling bug. But it correctly hides objects since the above works.
-[Unknown]
Wow, that's tricky. I have a branch somewhere with a prototype implementation of Z texturing, but not interpreting it as 565, lots of details to get right here.
Does this got to do with implementing something called "occlusion queries" ? As I understand this is also an issue on another emulator I know and that's what they said the solution is.