NBA Live 10 [ULES01310] - player's edges and floor are black

[ppmeis]

It could be related to #4109 because it seems to be same graphic engine and it's the same franchise/saga. Arms, legs and the floor are black.

[ppmeis]

Tried with latest build. Issues still present in both backends.

[ppmeis]

Tested with latest build. Same status.

[unknownbrackets]

Does #7515 improve this at all?

-[Unknown]

[ppmeis]

@unknownbrackets no it doesn't.

[ppmeis]

Tested with latest build. Same status:

[unknownbrackets]

I wonder if this is related to:

https://github.com/hrydgard/ppsspp/compare/hrydgard:master...unknownbrackets:clut-render?expand=1

-[Unknown]

[daniel229]

Nothing change after applying the clut-render branch

[daniel229]

JPCSP fixed the floor in jpcsp/jpcsp@6d64055

[unknownbrackets]

We essentially already do that, although we only do it for rectangles:

ppsspp/GPU/Common/SoftwareTransformCommon.cpp

Line 567 in 53f062b

result->stencilValue = transformed[indsIn[1]].color0[3];

I guess clear mode can be used with triangles? I'm not actually sure. Maybe that's the issue - does this game ever draw a prim while clear is enabled and the prim type is not rectangles? Easiest way to check would be logging here (inside the != RECTANGLES case):

ppsspp/GPU/Common/SoftwareTransformCommon.cpp

Line 483 in 53f062b

drawIndexed = true;

if (gstate.isModeClear() && gstate.isClearModeAlphaMask()) {
   WARN_LOG(G3D, "Hello, I'm Triangle Clearsalot.  And who might you be?");
}

-[Unknown]

[daniel229]

No,I don't see the log in the game.

When disabling stencil test

[ppmeis]

Tested with latest build. Same status.

[ppmeis]

Tested again. Same issues.

[ppmeis]

Tested with latest build. Same issues. This is one of the textures affected in arms and legs:

[unknownbrackets]

Since the texture is shown as black, we're definitely either:

• Decoding it (or its clut) wrong.
• Populating that memory wrong.
• Looking in the wrong place for it.
• Reading the data before it's populated or after it's changed without cache flush.

Per here:
#4109 (comment)

It could be we're reading the texture too early.

-[Unknown]

[ppmeis]

Tested in latest build. Good progress, now most of the players have color in arms, but now fingers are white or black and some color skin do not match with player (WTF?):

OpenGL default settings:

Vulkan:

Software rendering:

[unknownbrackets]

It would be very interesting to try to find the build where this behavior changed, it might point us to a more complete fix.

Looks like software just has culling / guardband bugs, but otherwise renders the arms and hands correctly.

-[Unknown]

[ppmeis]

I was looking for a first build made this change, all I can do is to notice that v1.2.2 had the issue and it was fixed on v1.3.

[ppmeis]

@unknownbrackets one step forward about investigation.

1.2.2-514-g306f742 arms and legs are black:

1.2.2-519-ga0ce802 arms and legs have color:

[unknownbrackets]

So that means #8757 helped this. Since we don't do that very aggressively, it's probably why the skin color is sometimes wrong.

In that case, we could do something similar to Danganronpa here and force readback for some framebuf, if we know which it is.

-[Unknown]

[ppmeis]

Tested with latest Windows build, default settings, same status:

[ppmeis]

Tested with latest Windows build, same status:

[unknownbrackets]

Could you try exporting a GE debugger dump on PC?

To do this, open the game and select Debug -> GE debugger..., then when it's displaying the scene, press Record in the top right. After a second or so, it'll finish and save a trace of the drawing activity.

After that, check the memstick/PSP/SYSTEM/DUMP folder and it'll have created a file named something like "ULES12345_0000.ppdmp". You can zip that and then drag and drop it into a reply here.

-[Unknown]

[ppmeis]

Tested with latest Windows build. Same issues. GE Debugger dump:

ULES01310_0001.zip

[benderscruffy01]

still happens
DUMP.ZIP

[ppmeis]

Tested with latest Windows build. Same issues

[ppmeis]

Tested in latest build. Same issues.

[unknownbrackets]

This is somewhat related to #4109.

In one of the latest frame dumps, I see white fingers at 10424/11216. It happens because the bottom part of the texture is gray:

This skin texture does seem to look like that generally...
0x0419e830 (64x64) - player 12

0x041b8c30 (64x64) - player 9

0x041ae430 (64x64) - player 20

0x041c5430 (64x64) - player 15

0x041a3c30 (64x64) - player 14

The gray and black at the bottom is the reason why the players have strange fingers or feet, because this texture is used for both arms and legs.

The floor is at 0x0416d7d0 (128x128) and it CLUT4. It being black suggests some sort of VRAM corruption, which was also already suggested by #8757 helping.

Focusing on 0x0419e830, it's 565 rather than even using a palette. Stride is 64, so it's neatly packed and not in the margin of anything else. It is swizzled. Looking at it without unswizzling:

It's clear the last part of it is strangely messed up. But it's E71C, so not a single byte or anything. Hard to say what it's supposed to be. A VRAM dump from the game running on a PSP would be helpful.

It'd also help to know when the game sets these memory regions, and if it's rendering them.

-[Unknown]

[ppmeis]

I can get my old PSP to live again. Could you tell me how to do a VRAM dump on real PSP?

[unknownbrackets]

First, get psplink. These instructions may work and are more recent:
http://pspdev.github.io/psplinkusb/

But this is how I've done it in the past:
https://github.com/hrydgard/pspautotests#prerequisites

Either way, get to this step:

Download the latest version of PSPLINK for the PSP here and extract it in ms0:/PSP/GAME on the PSP memory card.

Once you have that, we're going to do something different from either of the above: edit ms0:/seplugins/game.txt and add this line:

ms0:/PSP/GAME/psplink/psplink.prx 1

Once that's ready, you can turn off USB mode on the PSP and start the game. At this point, psplink is running as a plugin while the game is also running.

Next, open a wsl session and type usbhostfs_pc -b 3000. Then in another wsl session (leaving the previous one running), execute psplink -p 3000. If you're using the pspautotests instructions, these will be terminal windows instead, but it's similar.

Now, assuming your USB cable is connected, you should see the following in the usbhostfs_pc window:

USBHostFS (c) TyRaNiD 2k6
Built Mar 26 2009 16:26:00 - $Revision: 2368 $
sh> Connected to device

This means that the psplink plugin is running and everything is okay. If you don't see the Connected message, something is wrong with the connection or the game.txt setup.

Next, get to where ever in the game this happens.

Now in the psplink window, type:

savemem 0x04000000 0x00200000 vram.dat

You could also use 0x041a3c30 0x2000 player14.dat, but it's less certain the images are in those exact positions.

I did recently (in Silent Hill) have this behave strangely, but hopefully it works fine here. Alternatively you might use memdump 0x041a3c30 b, but this will only display a section of memory as a result instead of dumping to a file.

If anything goes wrong, you can press home on the PSP to quit the game and try again, this usually works.

-[Unknown]

[ppmeis]

@unknownbrackets I'm trying to use these tools but with Windows executables instead of WSL/Linux. Everytime I tried to launch savemem command there's an error:

[ppmeis]

This is the result of memdump 0x041a3c30 b command:

host0:/> memdump 0x041a3c30 b
         - 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f - 0123456789abcdef
-----------------------------------------------------------------------------
041a3c30 - 09 11 2B 11 09 11 09 11 2B 11 0E 22 70 32 91 32 - ..+.....+.."p2.2
041a3c40 - 2B 11 2B 11 09 11 8C 19 0E 22 0E 22 91 32 D2 3A - +.+......".".2.:
041a3c50 - 2B 11 2B 11 2B 11 0E 22 70 32 91 32 D2 3A 33 43 - +.+.+.."p2.2.:3C
041a3c60 - 8C 19 2B 11 8C 19 0E 22 91 32 D2 3A 33 43 74 4B - ..+....".2.:3CtK
041a3c70 - 8C 19 8C 19 8C 19 91 32 D2 3A 33 43 D6 53 37 5C - .......2.:3C.S7\
041a3c80 - 8C 19 8C 19 0E 22 D2 3A 33 43 33 43 37 5C B8 6C - .....".:3C3C7\.l
041a3c90 - 8C 19 8C 19 0E 22 D2 3A 74 4B 74 4B B8 6C B8 6C - .....".:tKtK.l.l
041a3ca0 - 8C 19 8C 19 0E 22 D2 3A 74 4B 74 4B B8 6C B8 6C - .....".:tKtK.l.l
041a3cb0 - 91 32 91 32 91 32 D2 3A D6 53 33 43 33 43 D2 3A - .2.2.2.:.S3C3C.:
041a3cc0 - D2 3A D2 3A D2 3A 33 43 37 5C D6 53 74 4B 33 43 - .:.:.:3C7\.StK3C
041a3cd0 - 74 4B 33 43 74 4B 74 4B 37 5C B8 6C D6 53 74 4B - tK3CtKtK7\.l.StK
041a3ce0 - D6 53 37 5C D6 53 D6 53 B8 6C B8 6C B8 6C 37 5C - .S7\.S.S.l.l.l7\
041a3cf0 - B8 6C B8 6C 37 5C B8 6C 7A 85 7A 85 7A 85 B8 6C - .l.l7\.lz.z.z..l
041a3d00 - B8 6C B8 6C 37 5C 7A 85 5C A6 5C A6 7A 85 7A 85 - .l.l7\z.\.\.z.z.
041a3d10 - B8 6C B8 6C B8 6C 7A 85 5C A6 5C A6 7A 85 7A 85 - .l.l.lz.\.\.z.z.
041a3d20 - 7A 85 B8 6C B8 6C 7A 85 5C A6 5C A6 5C A6 7A 85 - z..l.lz.\.\.\.z.