NBA Live 06 : Black texture (hand/leg) #4109
Comments
|
Just checked using softGPU , it is the same issue with black texture in hang/leg . |
|
Funny bug. Might just as well be lighting errors as textures though. |
|
I do believe it is the remaining lighting bug .Let me link up here .#4140 |
|
Does this still happen? -[Unknown] |
|
It is still happening aunfortunately |
|
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] |
|
Mostly , the original texture is black as well. |
|
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] |
|
Yep softgpu also the same black texture. |
|
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] |
|
Tested with latest build. Same issue: Lighting tab on GE Debugger: |
|
JPCSP works fine in softrendering dolphin also has the similar bug |
|
Does #7515 improve this at all? -[Unknown] |
|
No. |
|
No, #7683 does not help it. |
|
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] |
|
texture tab softgpu seems is fine since longtime ago.
|
|
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. 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... |
|
Tested with latest build. Same status. Here's the debugger dump: |
|
Erp, strike of "doesn't fix". Reopening. -[Unknown] |
|
What happened to the screenshots in the first post? Pretty sure those aren't of the game :D |
|
Still an issue at least test nba live 2010 |
|
One thing i found strange is that if you load the game with software mode and start the match then save stat it and then load the game with hardware mode the textures are no longer a problem unless a player will get substituted. So the emulator under hardware mode loads textures in error? |
|
it probably creates the textures through some draw calls that either fail, or never gets copied back to RAM at a point where the game grabs them to create the actual textures... |
|
Still happening in 2021. It's been 8 years already and we still have black arms. |
|
If it works in software, it's either a temp framebuffer being decimated or a not detected CPU modification of VRAM. What's the texture address that's incorrect in hardware but correct in software? If it's in VRAM (0x04xxxxxx), the next step is a breakpoint to find when it's being written to in software. -[Unknown] |
Software
Hardware VK
|
|
GE Dump using ppsspp latest git apk |
|
On a PSP, that latest frame dump shows incorrect arms: Looking at the player in the white jersey at the top (12), their limbs are all drawn from a texture that is 100% zero RGB:
This texture is 5650, so it's not a CLUT issue. Could set a breakpoint with the software renderer in debug mode to see when 0x041bba30 is written too. It's either rendered to, or a copy we don't detect. It's 0x2000 bytes (0x041bba30 - 0x041bda30). Their face looks good, and is a nearby texture at 0x041bda30:
It's possible something more complex is happening, like a render-to-clut and then single frame render-to-texture. But I suspect it's just a single frame draw where it colorizes textures. For reference, people with "working" legs looks like this:
Such as at 0x041d0a30. -[Unknown] |
|
Tested in latest build. Same issues. |
Just for record .
[removed nonsense non-screenshot pictures]
The text was updated successfully, but these errors were encountered: