Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
eleriaqueen opened this issue May 12, 2013 · 94 comments
Labels
Depth / Z Issue involves depth drawing parameters.

Comments

@eleriaqueen
Copy link

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.
image

When camera looks downwards the whole body is cut off.
image

When camera looks upwards the whole body is showing.
image

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)
image
image


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.
image


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
Copy link
Owner

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
Copy link
Author

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

@hrydgard
Copy link
Owner

Okay thanks.

@thedax
Copy link
Collaborator

thedax commented Jul 27, 2013

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
Copy link
Owner

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

@raven02
Copy link
Contributor

raven02 commented Jul 27, 2013

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
Copy link
Author

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
Copy link
Collaborator

thedax commented Jul 30, 2013

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

@raven02
Copy link
Contributor

raven02 commented Jul 30, 2013

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
Copy link

papel commented Jul 31, 2013

@raven02
ulus10529
(rename to zip)

@raven02
Copy link
Contributor

raven02 commented Aug 1, 2013

Many thanks @papel

@tommor
Copy link

tommor commented Aug 6, 2013

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

@unknownbrackets
Copy link
Collaborator

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

Unfortunately it doesn't say much about culling.

-[Unknown]

@tommor
Copy link

tommor commented Aug 7, 2013

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?
beztytuu1

@kenwu1992
Copy link

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%.
screen00000

@thedax
Copy link
Collaborator

thedax commented Oct 22, 2013

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
Copy link
Collaborator

thedax commented Dec 10, 2013

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):
Screenshot 01

@raven02
Copy link
Contributor

raven02 commented Dec 10, 2013

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

@Ritori
Copy link

Ritori commented Dec 10, 2013

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

@reinzhart
Copy link

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

sory for my bad english

@thedax
Copy link
Collaborator

thedax commented Dec 10, 2013

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
Copy link

@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
Copy link
Collaborator

thedax commented Dec 11, 2013

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

@reinzhart
Copy link

yes can you explain it?

@thedax
Copy link
Collaborator

thedax commented Dec 11, 2013

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
Copy link

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
Copy link
Owner

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
Copy link

Alright I just want this game to work.

@pinguallyj
Copy link

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

@Heoz
Copy link

Heoz commented Jul 28, 2014

Don't know if helpfull
GE no character when character on PPSSPP can see everything and standing on the ground
untitled
Second no option changed just resumed GE character show only when he's in the ground
untitled2

@Heoz
Copy link

Heoz commented Jul 28, 2014

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
Copy link
Collaborator

thedax commented Jul 29, 2014

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
Copy link

Heoz commented Jul 29, 2014

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
Copy link

Okay I just wonder when they would check this out.

@thedax
Copy link
Collaborator

thedax commented Jul 30, 2014

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.

Repository owner locked and limited conversation to collaborators Jul 30, 2014
@thedax
Copy link
Collaborator

thedax commented Jul 30, 2014

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 thedax changed the title [Graphic] [Phantasy Star Portable 2 US][x64] Draw distance, draw priority bugs, and transparency. [Graphics, OGL && D3D] [Phantasy Star Portable 2 US][x64] Draw distance, draw priority bugs, and transparency. Sep 30, 2014
@thedax
Copy link
Collaborator

thedax commented Sep 30, 2014

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

@unknownbrackets unknownbrackets added the Depth / Z Issue involves depth drawing parameters. label Dec 30, 2015
@unknownbrackets
Copy link
Collaborator

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
Copy link
Collaborator

Some light flicker instead
03

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

@unknownbrackets
Copy link
Collaborator

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

-[Unknown]

@unknownbrackets
Copy link
Collaborator

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
Copy link
Collaborator

The person seems brighter in software rendering.
06
07

If the savestate helps.(jpg to 7z)
npjh50043_2 00_2

@unknownbrackets
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

Yes, looks fine under 1x
08

@thedax
Copy link
Collaborator

thedax commented Sep 7, 2018

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
Copy link
Collaborator

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

-[Unknown]

@unknownbrackets
Copy link
Collaborator

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]

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Depth / Z Issue involves depth drawing parameters.
Projects
None yet
Development

No branches or pull requests