hrydgard / ppsspp

A PSP emulator for Android, Windows, Mac and Linux, written in C++. Want to contribute? Join us on Discord at https://discord.gg/5NJB6dD or just send pull requests / issues. For discussion use the forums at forums.ppsspp.org.
https://www.ppsspp.org
Other
11.45k stars 2.19k forks source link

NBA Live 06 : Black texture (hand/leg) #4109

Open dbz400 opened 11 years ago

dbz400 commented 11 years ago

Just for record .

[removed nonsense non-screenshot pictures]

dbz400 commented 11 years ago

Just checked using softGPU , it is the same issue with black texture in hang/leg .

hrydgard commented 11 years ago

Funny bug. Might just as well be lighting errors as textures though.

dbz400 commented 11 years ago

I do believe it is the remaining lighting bug .Let me link up here .https://github.com/hrydgard/ppsspp/issues/4140

unknownbrackets commented 10 years ago

Does this still happen?

-[Unknown]

dbz400 commented 10 years ago

It is still happening aunfortunately

GinIchimaru commented 10 years ago

Yeah,it's happening on '09 and '10 too...and the court is black,at least I'm experiencing that problem

unknownbrackets commented 10 years ago

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 10 years ago

Mostly , the original texture is black as well.

untitled

unknownbrackets commented 10 years ago

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 10 years ago

Yep softgpu also the same black texture.

screen00047

unknownbrackets commented 10 years ago

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 10 years ago

yep, JPCSP also same black texture.

(Not too sure how to do with it ........:( untitled

unknownbrackets commented 10 years ago

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 10 years ago

It could also write to normal vram and read from swizzled vram, thereby, well, swizzling the data the "other way".

unknownbrackets commented 10 years ago

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 10 years ago

Has this changed in the latest git build and "simulate block transfers" enabled?

-[Unknown]

unknownbrackets commented 10 years ago

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 10 years ago

Tested with latest build. Same issue: image

Lighting tab on GE Debugger: image image

daniel229 commented 9 years ago

JPCSP works fine in softrendering 01

dolphin also has the similar bug https://code.google.com/p/dolphin-emu/issues/detail?id=8207 02

unknownbrackets commented 9 years ago

Does #7515 improve this at all?

-[Unknown]

daniel229 commented 9 years ago

No.

unknownbrackets commented 9 years ago

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 9 years ago

No, #7683 does not help it.

unknownbrackets commented 8 years ago

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 8 years ago

texture tab 03

softgpu seems is fine since longtime ago.

01

02

unknownbrackets commented 8 years 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]

daniel229 commented 8 years ago

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 8 years ago

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 6 years ago

Tested with latest build. Same status. Here's the debugger dump: ULES00158_0001.zip

unknownbrackets commented 6 years ago

Erp, strike of "doesn't fix". Reopening.

-[Unknown]

hrydgard commented 6 years ago

What happened to the screenshots in the first post? Pretty sure those aren't of the game :D

Levan7 commented 4 years ago

Still an issue at least test nba live 2010

Levan7 commented 4 years ago

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 4 years ago

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 3 years ago

Still happening in 2021. It's been 8 years already and we still have black arms. Nobody has a clue?

unknownbrackets commented 3 years ago

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 3 years ago

Software

Screenshot_2021-08-29-12-07-18-014_org ppsspp ppsspp

Hardware VK

Screenshot_2021-08-29-12-08-53-055_org ppsspp ppsspp

ghost commented 3 years ago

GE Dump using ppsspp latest git apk NBALive06.zip

unknownbrackets commented 2 years ago

On a PSP, that latest frame dump shows incorrect arms: #4109_ULES01310_nba_arms2

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:

Simple black texture

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:

Face

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:

Leg texture

Such as at 0x041d0a30.

-[Unknown]

ppmeis commented 1 year ago

Tested in latest build. Same issues.