mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #4109] NBA Live 06 : Black texture (hand/leg) #1669
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#1669
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dbz400 on GitHub (Oct 11, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/4109
Just for record .
[removed nonsense non-screenshot pictures]
@dbz400 commented on GitHub (Oct 14, 2013):
Just checked using softGPU , it is the same issue with black texture in hang/leg .
@hrydgard commented on GitHub (Oct 14, 2013):
Funny bug. Might just as well be lighting errors as textures though.
@dbz400 commented on GitHub (Oct 14, 2013):
I do believe it is the remaining lighting bug .Let me link up here .https://github.com/hrydgard/ppsspp/issues/4140
@unknownbrackets commented on GitHub (Jan 5, 2014):
Does this still happen?
-[Unknown]
@dbz400 commented on GitHub (Jan 6, 2014):
It is still happening aunfortunately
@GinIchimaru commented on GitHub (Jan 7, 2014):
Yeah,it's happening on '09 and '10 too...and the court is black,at least I'm experiencing that problem
@unknownbrackets commented on GitHub (Feb 16, 2014):
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]
@dbz400 commented on GitHub (Feb 16, 2014):
Mostly , the original texture is black as well.
@unknownbrackets commented on GitHub (Feb 16, 2014):
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]
@dbz400 commented on GitHub (Feb 17, 2014):
Yep softgpu also the same black texture.
@unknownbrackets commented on GitHub (Feb 17, 2014):
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]
@dbz400 commented on GitHub (Feb 17, 2014):
yep, JPCSP also same black texture.
(Not too sure how to do with it ........:(
@unknownbrackets commented on GitHub (Feb 17, 2014):
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]
@hrydgard commented on GitHub (Feb 17, 2014):
It could also write to normal vram and read from swizzled vram, thereby, well, swizzling the data the "other way".
@unknownbrackets commented on GitHub (Feb 17, 2014):
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]
@unknownbrackets commented on GitHub (Jun 7, 2014):
Has this changed in the latest git build and "simulate block transfers" enabled?
-[Unknown]
@unknownbrackets commented on GitHub (Jun 15, 2014):
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]
@ppmeis commented on GitHub (Jul 21, 2014):
Tested with latest build. Same issue:
Lighting tab on GE Debugger:
@daniel229 commented on GitHub (Feb 21, 2015):
JPCSP works fine in softrendering
dolphin also has the similar bug
https://code.google.com/p/dolphin-emu/issues/detail?id=8207
@unknownbrackets commented on GitHub (Feb 24, 2015):
Does #7515 improve this at all?
-[Unknown]
@daniel229 commented on GitHub (Feb 24, 2015):
No.
@unknownbrackets commented on GitHub (Apr 13, 2015):
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]
@daniel229 commented on GitHub (Apr 13, 2015):
No, #7683 does not help it.
@unknownbrackets commented on GitHub (Dec 21, 2015):
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]
@daniel229 commented on GitHub (Dec 21, 2015):
texture tab
softgpu seems is fine since longtime ago.
@unknownbrackets commented on GitHub (Dec 22, 2015):
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]
@daniel229 commented on GitHub (Dec 22, 2015):
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.
@hrydgard commented on GitHub (Dec 22, 2015):
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...
@ppmeis commented on GitHub (Oct 21, 2018):
Tested with latest build. Same status. Here's the debugger dump:
ULES00158_0001.zip
@unknownbrackets commented on GitHub (Nov 22, 2018):
Erp, strike of "doesn't fix". Reopening.
-[Unknown]
@hrydgard commented on GitHub (Nov 22, 2018):
What happened to the screenshots in the first post? Pretty sure those aren't of the game :D
@Levan7 commented on GitHub (Mar 18, 2020):
Still an issue at least test nba live 2010
@Levan7 commented on GitHub (Mar 19, 2020):
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?
@hrydgard commented on GitHub (Mar 19, 2020):
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...
@jserodio commented on GitHub (Jan 16, 2021):
Still happening in 2021. It's been 8 years already and we still have black arms.
Nobody has a clue?
@unknownbrackets commented on GitHub (Jan 18, 2021):
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]
@ghost commented on GitHub (Aug 29, 2021):
Software
Hardware VK
@ghost commented on GitHub (Aug 29, 2021):
GE Dump using ppsspp latest git apk
NBALive06.zip
@unknownbrackets commented on GitHub (Oct 10, 2022):
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]
@ppmeis commented on GitHub (Dec 16, 2022):
Tested in latest build. Same issues.