[Graphics, OGL && D3D] [Phantasy Star Portable 2 US][x64] Draw distance, draw priority bugs, and transparency.

[eleriaqueen]

In Phantasy Star Portable 2 US there's a few bugs but they don't appear everywhere. First the one cutting the feet of the characters when camera is default.

When camera looks downwards the whole body is cut off.

When camera looks upwards the whole body is showing.

Also if you look closely, not only the body is cut off, but parts of the background too, light-like effects and transparent hologram-like screen don't show on default and downwards camera. And the door appears sometimes and sometimes it doesn't.

When in complete upwards looking camera position everything is displayed (it seems) but as soon as you move the camera just an inch up a lot of the background disappears.

---

Some Background Objects only appear when close to them which is wrong. (notice the bug in the font, the "i" are too thin, and spacing is wrong)

---

Also, photon weapons should be tranparent but they're not, they're also missing their glow (you know the glow that hovered over the characters quite a few revisions back)
Also weapons are not drawn correctly when a character is behind.

---

There are no errors in Debug Log, except the issue I mentioned there : #1785

Get this fixed and a lot of the game will be playable as now as of 0.7.6 - 547 there are character portraits and game is running pretty well, and I CAN LOAD MY PSP CHARACTERS FINE !!

[hrydgard]

Most of these would appear to be VFPU math bugs (the game seems to be using the wrong camera direction when deciding what to draw), the weapons-under-characters thing might not be though. Is this with buffered rendering enabled or disabled, or doesn't matter?

[eleriaqueen]

It's WITH buffered rendering enabled, actually without buffered rendering nothing shows on the screen (black)

[hrydgard]

Okay thanks.

[thedax]

Something to possibly take note of: @neobrain's softGPU doesn't experience the disappearing bodies issue, so maybe we can take a page out of its book for a depth fix? It doesn't seem to be a VFPU bug if it's not present in softGPU.

Opinions, @raven02, @hrydgard ?

[hrydgard]

yeah, definitely not VFPU then. It's great to have an emerging software implementation that can prove such things :)

[dbz400]

It is good to hear .

@thedax , wondering how the softGPU looks like ? i didn't compile one yet to test .Would it be highly pixlated ?

[eleriaqueen]

I briefly saw my brother use PPSSPP compiled by emucr but don't remember the version, anyway the bug was only partially there, you could see much further ahead at normal camera angle. So I went to try a new version of PPSSPP when I went home only to realise on my computer the bug remained unchanged !

He has a gtx 560 TI, while I have a standard 660. Processor are both Intel I5, mine is a 3570.

[thedax]

@raven02: Yeah, it's pixellated and has a few polygon issues, but it doesn't have the depth issue:

[dbz400]

Thanks @thedax .I'm trying to find out the code difference , hopefully we can port the correct code here for GLES .

btw, do you mean sharing this save point to me ?

[papel]

@raven02

(rename to zip)

[dbz400]

Many thanks @papel

[tommor]

Dont know if it'll help but i get something like this in Debug Statistics while the bug is occuring.

[unknownbrackets]

Wow, that's a lot of time in __KernelReturnFromInterrupt().

Unfortunately it doesn't say much about culling.

-[Unknown]

[tommor]

From what i see there shouldnt be any __KernelReturnFromInterrupt as you can see from this screenshot theres a lot of difference when the bug is not happening and syscalls that appear are: sceDisplayWaitVblankStartCB, sceloOpen and __sceSasCoreWithMix. Maybe the bug is in one of them?

[kenwu1992]

I find that at v0.9.1 build, choosing "Software rendering" instead of "OpenGL rendering" under "Emulation">"Rendering Backend" can fix the graphic problem. However, the speed will drop to around 10%.

[thedax]

That's to be expected, it's software. Also, I posted about this a while back. It's a problem with OpenGL, not the CPU or anything.

[thedax]

I did some more digging with this issue and found JPCSP has the same problem. If I mess with zScale and zOff in StateMapping for GLES, I can get differing results, some of which horribly break the game, and others which improve it (not sure what the correct values should be, though).

Edit 1: If I ignore the zScale part of depthRangeMin = zOff - zScale (e.g. making it depthRangeMin = zOff), the issue disappears, but other things are still screwy (things that should be hidden behind walls are visible). Is the minimum range being calculated incorrectly?

Here's a screen of when the depthRangeMin is simply set to zOff (notice how some things such as the galaxies and some of the computer screens behind the doors should not be showing, but are anyway):

[dbz400]

Wondering did JPCSP fix this issue in GL mode? I remember it also only work in software mode only previously

[Ritori]

@raven02 yup it work with software mode.
use latest version.

[reinzhart]

still not fixed yet on latest release
i hope it fixed soon

sory for my bad english

[thedax]

Well yeah it's not fixed, I was merely sharing information that might help someone get an idea with what's wrong. I know for a fact the "fix" I found by tinkering is wrong, and will probably break way more games than this, so it's not worth adding.

[reinzhart]

@thedax sory to bump again but are you running in software rendering in post up there?
if not can you explain how to run like that,i download StateMapping and edited the line like you said seems nothing change
suck to be newb but i want to learn
thx for response

[thedax]

In the comment I posted about zScale and such? No, that was with OpenGL.

[reinzhart]

yes can you explain it?

[thedax]

There's not really much to explain. Change line 517 of GLES' StateMapping from

float depthRangeMin = zOff - zScale;

to

float depthRangeMin = zOff;

And you should get the same results that I got up there, once you recompile it.

[CurdledSteak]

Qustion was the software rendering fix the ddisappeaing problem but makes it alot slower. IS There a way to make it faster like buffe rendering.

[hrydgard]

Making a fast software renderer is a large amount of development work, it's not just flipping a setting. It'll probably happen but likely not very soon.

[CurdledSteak]

Alright I just want this game to work.

[pinguallyj]

Draw distance also appear as problem in some games too, but only with enemy sprites.

[Heoz]

Don't know if helpfull
GE no character when character on PPSSPP can see everything and standing on the ground

Second no option changed just resumed GE character show only when he's in the ground

[Heoz]

Correct me if i am wrong but second picture have full picture on GE doesn't it means that second one is normal on GE is opposite how the picture on PPSSPP represent where you standing on the ground picture missing everything on GE it's missing triangle clipping it's hard to explain :O

[thedax]

We already know how to reproduce it, so posting about changing camera angles again won't help much. As I said, we just have to be patient until Unknown or Henrik take a look at the data we've provided.

[Heoz]

Cool cool i read that someone asked if it's possible to make a game normal on OpenGL he didn't see that character on OpenGL can stand on the ground when camera is changed so it's possible to make it :D

[CurdledSteak]

Okay I just wonder when they would check this out.

[thedax]

They'll check it out when they're ready.

@hrydgard or @unknownbrackets: May I suggest we lock the issue to collaborators only at this point? There's not really anything new to find that we don't already know, I think. Unfortunately though, I won't be able to respond to the issue should you decide to do so if you need a tester, since I'm not a collaborator.

[thedax]

I noticed I was made a collaborator (thanks @hrydgard :) ), so I'll go ahead and lock this for now. We'll open it back up once there's more to discuss.

[thedax]

Both OpenGL and Direct3D are affected by this, so I updated the title (making it relevant so dupes can be closed, like #6961).

[unknownbrackets]

So, just to clarify and summarize what's going on here, at least from what I can tell.

1. It's not that the invisible things are being clipped. They're drawing inside normal depth bounds.
2. Regular src > dst depth tests are simply failing; they are why things aren't drawing.
3. It's not really a rounding issue; the difference in the existing depth (e.g. 44304) and the drawn depth (e.g. 44051) is larger than that.

Now, the game, when drawing it's scenery, does a lot of drawing with wild coordinates. They're probably not wrong, but many are significantly outside the valid window space, so it's possible this is a clipping issue; maybe the draw that's establishing the depth values that the future tests fail on is a draw that should be culled/clipped entirely.

Another possibility is that it's a vertex ordering issue; maybe somehow the later vertices that establish the wrong depth should be failing tests.

But, I don't really think it's that, because the scenery visually looks correct. And also because of the hack which currently works around this issue.

So, when drawing the backgrounds, it uses this viewport:

Viewport Scale 240.000000, -136.000000, -27635.000000
Viewport Offset 2048.000000, 2048.000000, 26116.000000
Min Z 002710 (10000)
Max Z 00fef6 (65270)

When drawing the character (specifically the part that fails to show up), it uses this one:

Viewport Scale 240.000000, -136.000000, -27635.000000
Viewport Offset 2048.000000, 2048.000000, 37635.000000
Min Z 002710 (10000)
Max Z 00fef6 (65270)

Below, remember that the output of vertex depth (vz) is going to be in the range of [-1, 1]. Anything outside that is clipped. So, while drawing the backgrounds, z works like this:

z = (vz * -27635) + 26116
z = [-1519, 53751]

After that, anything outside min/max z is clipped as well. So the final range of z is [10000, 53751].

When drawing the character, the range is simply [10000, 65270] form the start. In this case, minz/maxz are not needed, because the viewport is already equivalent.

Here's the issue, though: glDepthRange (which we use to establish the viewport range) CLAMPS its inputs. I think this is mentioned above, but just clarifying it here. What this means is that the scenery, which was supposed to use:

z = (vz * -27635) + 26116
z = [-1519, 53751]

Ends up using:

z = (vz * -26875.5) + 26875.5;
z = [0, 53751]

As you can see, this is a completely different formula. And it'll bias the z output values higher by about 3% - just enough to make a depth tests near the floor and stuff fail.

With this, we arrive at the depth range hack. This attempts to adjust the viewport (just as we do for X and Y) to account for this clamping.

Really, it should be completely possible to implement this in a way that works with all games and can simply be statically enabled, as we already do with x and y. The only tricky part is that clipping needs to still work correctly. I'm not sure what "correctly" means in this context; ultimately fragments outside minz/maxz should not be drawn.

-[Unknown]

[daniel229]

Some light flicker instead

the 4 and 5 picture in the top post still happen.

[unknownbrackets]

I'll reopen for the flicker. But, picture 4 and 5 may simply be a render resolution issue.

-[Unknown]

[unknownbrackets]

I'm not able to reproduce the font issue, even at higher resolutions?

Could you post a savestate that reproduces the photon weapon issue and the background object issue? The glowing swords seem to be layering correctly...

For the flicker, maybe we need to use pixel depth rounding... hmm.

-[Unknown]

[daniel229]

The person seems brighter in software rendering.

If the savestate helps.(jpg to 7z)

[unknownbrackets]

That seems right near the start, okay. I will bust out my PSP, but the plasma sword or whatever it is seems to be layering properly.

-[Unknown]

[unknownbrackets]

So, on a PSP-2000, using a US region game, the following notes:

• Layering of the saber is the same. It is behind her to a point, and there's an area where it overlaps partially, and then it's in front. Nothing looks unsual.
• All colors are visually greener than my PSP-2000 screen, which looks bluer. This applies to the entire screen, which is probably colder. I think my PSP-3000 had an option for color temperature.
• The shield looks perhaps a bit duller and bluer on the PSP compared to OpenGL, but pretty much the same. The software rendering above is definitely different and wrong (looks like wrong lighting.)
• The red bars on the door appeared only when I entered the room. The effect matched the PSP.
• The girl, when out of view, faded out slightly. The effect matched the PSP.

So at least in the intro area, I didn't notice any differences. I might've just missed it, though. Could it be the problems are different with the JP region game?

-[Unknown]

[daniel229]

Yes, looks fine under 1x

[thedax]

Out of curiosity, I revisited the core issue of background objects and characters disappearing based on the camera angle and distance, and it seems that only OpenGL still needs the DepthRangeHack set to true in compat.ini. D3D9, D3D11, and Vulkan don't have the issue from what I could see (even with DepthRangeHack set to false). Tested with commit g562c5f648.

[unknownbrackets]

Probably means that the "accurate depth" path used on the other backends is doing depth correctly in this case.

-[Unknown]

[unknownbrackets]

This hack is now only used when depth clamp is unsupported on GLES/OpenGL. It's working correctly without the hack in situations where we are using the "accurate depth" path, so I'm going to close this.

-[Unknown]