ppsspp
ppsspp copied to clipboard
hrydgard
NBA Live 06 : Black texture (hand/leg)
Just checked using softGPU , it is the same issue with black texture in hang/leg .
I do believe it is the remaining lighting bug .Let me link up here .https://github.com/hrydgard/ppsspp/issues/4140
Yeah,it's happening on '09 and '10 too...and the court is black,at least I'm experiencing that problem
What does it look like when it's about to draw those things in the GE debugger?
https://github.com/hrydgard/ppsspp/wiki/How-to-find-a-graphic-issue-with-the-GE-debugger
-[Unknown]
Hmm, I wonder if it's a block transfer or something then to that address. Sounds like our problem is that the texture is black and shouldn't be.
I assume it's also black in the softgpu, right? I wonder if it's accessing swizzled vram or something...
-[Unknown]
Okay, try pausing it right when you load the game (soon as possible, or better yet turn off "run on load"), and set a memory breakpoint for 0x04200000 of size 0x00600000. Then run it, don't load state, and try to get there again.
If it trips the breakpoint, it's trying to write somewhere into swizzled vram.
Also, does JPCSP show them correctly, or also black? I don't think it supports the swizzled vram either but I don't really know.
-[Unknown]
yep, JPCSP also same black texture.
(Not too sure how to do with it ........:(
Before it runs any code. Also, both addresses should have 8 digits (just copying them should be fine.)
Once you hit okay, just run. Emulation will automatically stop when the game tries to access that range.
-[Unknown]
It could also write to normal vram and read from swizzled vram, thereby, well, swizzling the data the "other way".
Sure, but that texture address appears to be regular vram.
Of course, it could also be a block transfer or something. Probably a good idea to set a breakpoint for 0x100 bytes at the texture address too.
-[Unknown]
Has this changed in the latest git build and "simulate block transfers" enabled?
-[Unknown]
Also, a copy or screenshot of the lighting tab when it's about to draw a hand/leg would be helpful (on the prim.) As well, does it use mipmap levels (will show Level + button)?
-[Unknown]
JPCSP works fine in softrendering
dolphin also has the similar bug
https://code.google.com/p/dolphin-emu/issues/detail?id=8207
I don't suppose this is similar to #7682 after all and #7683 helps? We've focused on lighting, so I'm not sure what the clut address is here.
-[Unknown]
This still happens in softgpu right?
The texture data must be wrong. It's not a swizzled mirror though, so I wonder how it can be wrong in softgpu... hmm. It seems it doesn't use a palette. Can I see the entire texture tab?
Some of them even have psychedelic arms in that last screenshot in Dolphin.
-[Unknown]
Odd, negative UV offset, but it has wrapping anyway.
It's not using any CLUT. So I guess it's either drawing to that 64x64 or writing to it. We checked mirrors already, right?
My goal is to figure out who is responsible for filling the texture at 0x041cb630. Are there ever any logged FBOs for "0x001cb630" or "0x041cb630"? If you set a memory breakpoint at 0x041cb630 (size = 0x2000), does it ever trip?
-[Unknown]
I got this log from the breakpoint. https://gist.github.com/daniel229/695dc1af06877288cce3
Dolhine post said Dolphin's issue is a dualcare timing issue,and it works fine in single core.
Given the dolphin problem, sounds to me like the game might be filling out the texture with the right color at some point in time without synchronizing properly with the GPU - and we might be processing display lists "too fast" as seen from the PSP CPU...