Zig-PSP Homebrew example program won't emulate

[silbinarywolf]

Game or games this happens in

EBOO00649 - Zig PSP Test

What area of the game / PPSSPP

Here's the compiled file from source here on the Zig-PSP repo: https://cdn.discordapp.com/attachments/715392301723156492/1144786374923407371/EBOOT.PBP

Program just has a grey screen on latest stable and absolute latest build

What should happen

Should show a textured box rotating.

Video running on PSP-1002: https://cdn.discordapp.com/attachments/715392301723156492/1144785484355207229/IMG_0679.mov)

Logs

From latest build at time of writing ppsspplog.txt

Platform

Windows

Mobile phone model or graphics card

NVIDIA GeForce GTX 1650 SUPER

PPSSPP version affected

v1.15.4

Last working version

Haven't tested on older/newer versions

Graphics backend (3D API)

Direct3D 11

Checklist

• [X] Test in the latest git build in case it's already fixed.
• [X] Search for other reports of the same issue.
• [X] Try resetting settings or older versions and include if the issue is related.
• [X] Try without any cheats and without loading any save states.
• [X] Include logs or screenshots of issue.

[anr2me]

It ran if you use Software renderer

Some homebrew doesn't shows up on PPSSPP when using hardware renderer as i remembered (even my simple test prx files won't shows the printed text/logs on screen while it shows up on JPCSP)

[silbinarywolf]

Ah awesome! I did try to look for a setting like this but I'm blind I guess 😅

Happy for this issue to be closed. At least if someone else specifically searches for this, they'll find this thread and see they need to turn on software rendering.

[hrydgard]

It may still be worth looking at, and either fixing PPSSPP or the Zig example.

Generally if something renders only in the software renderer, it's doing something in an inefficient or semi-wrong way, although there is also the possibility that PPSSPP's hardware renderers have a bug.

[silbinarywolf]

Since the Zig-PSP stuff is based off of Rust-PSP, I'd say that if Rust-PSP renders fine, but Zig doesn't, then it's likely an issue with the Zig implementation.

I decided to look into it right now and Rust-PSP seems to be fine with hardware rendering:

This Zig-PSP work isn't actively maintained anymore (2 years old) so maybe chalk this up to Zig-PSP being incorrect?

Here's the EBOOT.pbp for Rust-PSP's "Cube" example: https://cdn.discordapp.com/attachments/715392301723156492/1145143844363587584/EBOOT.PBP

[hrydgard]

OK, investigated this in RenderDoc.

The entire cube gets clipped away, I guess we're just very slightly off from what the real PSP is doing.

The reason this is happening is that there's a digit missing in the projection matrix, causing it to squish the cube flat against the Z=0 plane, so this cube will not depth test properly against anything else. The perspective projected texturing still works (if you pass the clipping) since the W coordinate is computed correctly.

Note how the third row (actually column, I believe, but viewed transposed) of the matrix is 0.0f. There should be at least one non-zero number in there.

Note that we are not hitting range culling like in #17061 . However, clipdistance[1] in the VS output is NaN:

which might be related to:

So maybe our Z clipping is very slightly off.

[hrydgard]

Actually, the source of the problem is when we compute the u_depthRange which is used for clipping.

In ShaderUniforms.cpp, in if (dirtyUniforms & DIRTY_DEPTHRANGE) { we get the vpZScale, check that it's not zero and divide by it. Unfortunately, it's not zero but incredibly small, so small that dividing by it still produces an INF!

Never seen this case before...

1.0f / -4.592e-41#DEN = inf!

And an inf there leads to havoc in the math that follows eventually leading to garbage parameters to the vertex shader and nothing gets rendered.

Anyway, my recommendation is to fix the Z viewport range and the projection matrix in the sample, if anyone still works on it! And, we should probably add some checking to be safe from this.

The following is sufficient to get it to render:

        if (my_isinf(inverseDepthScale)) {
            inverseDepthScale = 0.0f;
        }

[hrydgard]

@silbinarywolf I've fixed this in PPSSPP now, but again, as mentioned above, the sample has some problems :)