Nba jam menu Only renders the background

[Triticum0]

Title

https://xemu.app/titles/41430013/#NBA-Jam

Bug Description

The text and charterers on the menu screen are missing

xemu:

xemu:

xemu:

Expected Behavior

xbox:

xbox:

xbox:

xemu Version

Version: 0.6.2
Branch: master
Commit: bbcd576
Date: Sat Oct 30 23:09:11 UTC 2021
Last-known Working: N/A

System Information

Field	Value
OS	Windows 10 64-bit (21H1)
CPU	AMD Ryzen 5 2600 Six-Core Processor @ 3.40GHz
Graphics Device	AMD Radeon RX 5700 XT
Graphics Driver	4.0.148202 Core Profile Context 21.3.2 27.20.15003.5017

Additional Context

Interesting tidbit the same bug on Nba jam also occurs on pcsx2
Seem to be an ordering problem.

[abaire]

If you're up to it, I'd be very interested in what happens if you enable DEBUG_NV2A_REG and log the output. Specifically any line that include PVIDEO would be of interest.

It's possible that NBA Jam uses a color key that has alpha (which is why it wasn't fixed along with SeaBlade by #669) or that it's using an entirely different mechanism to render the background.

[Triticum0]

I try to but i did get any output log on window do I need to enable this as well for it to work?

[abaire]

Oh, yes, sorry! You do need both.

[Triticum0]

@abaire I'm not sure where Xemu stores the log or how to output the terminal to a log. So it is not all the terminal output due to the terminal line limit. My anti-virus software on windows was giving me problems, so I had to reinstall Ubuntu to do the testing. So it took a while to do the testing.

[abaire]

@Triticum0 no problem, I appreciate your help!

I don't see any pvideo invocations in that log so it may be that NBA Jam is actually not the same issue as SeaBlade (which was a problem with a particular mechanism for doing color keyed videos).

FYI if you're testing on Linux, the easiest way to capture the log is to run from terminal and pipe it to a file: E.g., if you're in the "dist" directory after building:
./xemu.app -dvd_path path_to_the_xiso_to_test > log.txt

In this case I'm most interested in the pvideo lines so you could even pipe through grep to limit the amount of data:
./xemu.app -dvd_path path_to_the_xiso_to_test | grep -i "PVIDEO" > log.txt

[Triticum0]

@abaire I tried that and it said (bash: ./xemu.app: No such file or directory) do I need the make the directory first to do it. I not very knowable in how Linux terminal works so might be a dumb question.

[Triticum0]

I've never use terminal to mount ISO before so i not sure what I'm doing wrong to not get an log. Are you meant to go into the .ini file to get the log to work?

[abaire]

@abaire I tried that and it said (bash: ./xemu.app: No such file or directory) do I need the make the directory first to do it. I not very knowable in how Linux terminal works so might be a dumb question.

Yup, you need to cd into whatever directory you have xemu in.

I was on macOS when I wrote those instructions and erroneously put ".app" on the end, you're probably already doing the right thing and just need ./xemu without the .app suffix (which is specific to macOS app bundles) - sorry about that!

On linux you want something like:
./xemu -dvd_path path_to_the_xiso_to_test > log.txt

after cd-ing into the xemu/dist directory.

[Triticum0]

@abaire I got it working just now. Thank you for the help. Removing .app did the trick. I will send the log soon. Also will do a log for some of the other issues, that I created, but I'm not sure how pgraph.c#L27 and pgraph.c#L28 to 1 changes the output in any way, same with DEBUG_NV2A_REG. They don't seem different from just enabling debug. I do get other values when I use nv2a: Make nv2a_dprintf toggleable pr and untoggle log output, but I might just not have enough to tell the difference. I Just want to make sure I'm doing this correctly, so the logs are useful. Please say what log you think will be useful for the 54 issues I created, and I will get on with making logs for them all so they can get solved.

[Triticum0]

Here the full log file
log.zip

[abaire]

@abaire I got it working just now. Thank you for the help. Removing .app did the trick. I will send the log soon. Also will do a log for some of the other issues, that I created, but I'm not sure how pgraph.c#L27 and pgraph.c#L28 to 1 changes the output in any way, same with DEBUG_NV2A_REG. They don't seem different from just enabling debug. I do get other values when I use nv2a: Make nv2a_dprintf toggleable pr and untoggle log output, but I might just not have enough to tell the difference. I Just want to make sure I'm doing this correctly, so the logs are useful. Please say what log you think will be useful for the 54 issues I created, and I will get on with making logs for them all so they can get solved.

The DBG_SURFACES defines are only useful for a very particular class of bugs. DEBUG_NV2A_REG is also only interesting for a subset of bugs, though it's broader than the surface stuff and is specifically interesting for things like SeaBlade that use the pvideo subsystem. I wouldn't bother enabling the two in pgraph.c, but I would expect DEBUG_NV2A_REG to print out a bunch more data than DEBUG_NV2A alone (though they'll all start with nv2a: so it might not be immediately obvious if you don't know what to look for).

The log you attached is exactly what I was looking for, the lines like nv2a: PMC: read [0] -> 0x2a000a3 mean that DEBUG_NV2A_REG is correctly enabled.

I still don't see any PVIDEO manipulation though, so I'm pretty confident now that the failure for this game is something different from SeaBlade and will need to be debugged some more. I'll take a deeper look at the log in the coming days and see if there's anything obviously wrong, otherwise I'll see if I can find it cheap on eBay :)

At the moment I wouldn't bother doing logs for all 54 issues, I've ordered a number of the games you've reported on and it's probably faster for me to debug directly where I can actually see the data on top of the pgraph logs. It won't hurt to have logs, but they're not always directly useful and I don't want to waste your time! If you don't mind, I'll tag you when I come across bugs where a log would be helpful.

[abaire]

Looking at the log in more detail, I see a lot of unhandled commands for 0x1e90 and 0x1e80 which may be important. They're nestled in between modifications to the vertex shader constants and the vertex shader itself so I'd guess they're somehow related to vertex shading?

[Triticum0]

This is mostly fixed with #1080

[Triticum0]

@abaire You fixed the menu issue It doesn't happen in latest build

[Triticum0]

But the shadows are still broken look like vsh issue

2022-06-25.11-53-48.mp4