mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-04-24 21:56:10 +03:00
[GH-ISSUE #1788] [Graphics, OGL && D3D] [Phantasy Star Portable 2 US][x64] Draw distance, draw priority bugs, and transparency. #594
Labels
No labels
Atrac3+
Audio
CPU emulation
D3D11
D3D9 (removed)
Depth / Z
Feature Request
Font Atlas
GE emulation
Guardband / Range Culling
HLE/Kernel
I/O
Input/Controller
MP3
Multithreading
Needs hardware testing
Networking/adhoc/infrastructure
No Feedback / Outdated?
OpenGL
PGF / sceFont
PSMF / MPEG
Platform-specific (Android)
Platform-specific (Windows)
Platform-specific (iOS)
PowerVR GPU
SDL2
Saving issue
User Interface
Vulkan
arm64jit
armjit
armv6
x86jit
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ppsspp#594
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @eleriaqueen on GitHub (May 12, 2013).
Original GitHub issue: https://github.com/hrydgard/ppsspp/issues/1788
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 : https://github.com/hrydgard/ppsspp/issues/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 commented on GitHub (May 13, 2013):
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 commented on GitHub (May 13, 2013):
It's WITH buffered rendering enabled, actually without buffered rendering nothing shows on the screen (black)
@hrydgard commented on GitHub (May 13, 2013):
Okay thanks.
@thedax commented on GitHub (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 commented on GitHub (Jul 27, 2013):
yeah, definitely not VFPU then. It's great to have an emerging software implementation that can prove such things :)
@dbz400 commented on GitHub (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 commented on GitHub (Jul 27, 2013):
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 commented on GitHub (Jul 30, 2013):
@raven02: Yeah, it's pixellated and has a few polygon issues, but it doesn't have the depth issue:
@dbz400 commented on GitHub (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 commented on GitHub (Jul 31, 2013):
@raven02
(rename to zip)
@dbz400 commented on GitHub (Aug 1, 2013):
Many thanks @papel
@tommor commented on GitHub (Aug 6, 2013):
Dont know if it'll help but i get something like this in Debug Statistics while the bug is occuring.
@unknownbrackets commented on GitHub (Aug 6, 2013):
Wow, that's a lot of time in
__KernelReturnFromInterrupt().Unfortunately it doesn't say much about culling.
-[Unknown]
@tommor commented on GitHub (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?
@kenwu1992 commented on GitHub (Oct 22, 2013):
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 commented on GitHub (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 commented on GitHub (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):
@dbz400 commented on GitHub (Dec 10, 2013):
Wondering did JPCSP fix this issue in GL mode? I remember it also only work in software mode only previously
@Ritori commented on GitHub (Dec 10, 2013):
@raven02 yup it work with software mode.
use latest version.
@reinzhart commented on GitHub (Dec 10, 2013):
still not fixed yet on latest release
i hope it fixed soon
sory for my bad english
@thedax commented on GitHub (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 commented on GitHub (Dec 11, 2013):
@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 commented on GitHub (Dec 11, 2013):
In the comment I posted about zScale and such? No, that was with OpenGL.
@reinzhart commented on GitHub (Dec 11, 2013):
yes can you explain it?
@thedax commented on GitHub (Dec 11, 2013):
There's not really much to explain. Change line 517 of GLES' StateMapping from
to
And you should get the same results that I got up there, once you recompile it.
@tommor commented on GitHub (Jan 9, 2014):
I know its a stupid question but have you tryed something like:
float depthRangeMin = zOff - (zScale/2);or something of that kind?
I would have experimented on my own but thanks to college i dont have enough time atm to resolve the errors i encountered while installing visual studio and directx sdk :/
@thedax commented on GitHub (Jan 9, 2014):
Same results as the other hack, basically. I'm guessing both min and max will have to be tweaked/corrected.
@ghost commented on GitHub (Jan 9, 2014):
Just started playing with PPSSPP and ran into this thread when trying to find a solution to the problem. So there doesn't seem to be a solution I take it?
@thedax commented on GitHub (Jan 9, 2014):
Not an official solution, no. If you can make your own builds, you can try some of the hacks we've messed with to get a half decent result, but it won't be 100% perfect nor accurate at all (which is why such a hack isn't in the master).
@tommor commented on GitHub (Jan 9, 2014):
Guess ill need to find some time in the near future to install all the needed packets to tweak the min/max values cos this game is worth it especially if adhoc/online support will be added for it.
@ghost commented on GitHub (Jan 10, 2014):
@thedax Sorry to bump this again as well, as there's not much anyone can do, but thedax what do you mean when you say change line 517 of GLES? I'm sorry, I know almost nothing about coding. If it's not worth trying to explain to a total noob I'll just walk away. Sorry, I'm sure you're busy, I was just wondering.
Haha, it's just this is the only game I really really wanted to play on the PSP, and I don't mind your "breaking" glitch as long as I can see everything. Or maybe just test it out.
Edit: Did some digging. I'm working on doing all this right now. You guys are amazing. How do you learn all this. http://forums.ppsspp.org/showthread.php?tid=5231
@lakshun commented on GitHub (Jan 26, 2014):
I get this problem not just in the lobby but also in missions with characters, enemies and objects (like doors or boxes) but partially or entirely invisible.
@thedax commented on GitHub (Jan 26, 2014):
Yep, it happens everywhere.
@kirbysuperstar commented on GitHub (Jan 26, 2014):
Actually it works perfectly in your character's Room. At least on Infinity, but I assume it's the same for PSP2 itself.
@lakshun commented on GitHub (Feb 8, 2014):
I'd try debugging this myself but I'm a C# programmer and I don't know the first thing about graphics programming.
Still, if it's a problem with the distance maybe it's possible to create a workaround/hack for this game only (possibly with different settings for different areas) even if this would break other games.
I downloaded the ppsspp source but somehow a lot of files were missing, not sure where I can find the full version, including all resources.
And does anyone know a good tutorial that can tell me the basics of graphics programming (really only enough to work on this issues)?
@unknownbrackets commented on GitHub (Feb 8, 2014):
Well, first thing's first, you probably need to run
git submodule update. I think there's a topic on the forum about getting this compiled.-[Unknown]
@solarmystic commented on GitHub (Feb 8, 2014):
@takshun
Compiling ppsspp on Windows? Might I humbly suggest this guide on the forum that I've written up for such an occasion. http://forums.ppsspp.org/showthread.php?tid=5231
@lakshun commented on GitHub (Feb 9, 2014):
Thanks, anyone got the link for the windows 7 version of VS 2013? I can only find the win 8 version
@solarmystic commented on GitHub (Feb 9, 2014):
@lakshun
It's the same one in the guide I linked to. Make sure you download Visual Studio Express 2013 for Windows Desktop which supports Windows 7.
This one:-
http://www.visualstudio.com/en-us/products/visual-studio-express-vs
@Emerald-Drakull commented on GitHub (Mar 25, 2014):
Say I was wondering if anyone would be kind to share the PPSSPP build to download. I can't really program at all worth my life and even when looking at the guide I couldn't make heads or tails out of it. If it's alright would someone be so generous to kindly link me a download to the graphic fixed PPSSPP build? Or maybe point me in the direction to where I can download it. Sorry for wasting time and text it's just I mostly downloaded PPSSPP for that game and it makes it almost impossible to play.
So if someone could point me to the direction where I could obtain a download the the codded build that fixes that error or if someone could share the build I'd be most thankful.
@thedax commented on GitHub (Apr 20, 2014):
Since nobody's taken the liberty of using the GE debugger to put info up here, I'll go ahead and dump some info here that might shed a bit more light on the depth problem:
I took this info when the debugger looked like this, exhibiting this character's missing feet/legs:
Info dump: https://gist.githubusercontent.com/thedax/ea528d140aa348eef767/raw/4891ed28df1e94df0bfe0781b53727e86479b13e/gistfile1.txt
@thedax commented on GitHub (Jun 4, 2014):
@hrydgard / @unknownbrackets: Does the info I dumped reveal anything unusual? Just curious.
@CurdledSteak commented on GitHub (Jul 13, 2014):
Hello was there a fix to this problem let. I thought 0.9.8 would fix the problem, but I still that graphics glithes their. So I'm hoping someone found a fix to this problem. I really hate, not able to see my character. So yea thank you for the help
@thedax commented on GitHub (Jul 13, 2014):
Nope, hence why the issue is still open. Still patiently waiting for @hrydgard or @unknownbrackets to look at it.
@CurdledSteak commented on GitHub (Jul 15, 2014):
I hope the next one has this fix. Because that is one of the coolist games in the world.
@CurdledSteak commented on GitHub (Jul 20, 2014):
Those 2 guys are the one who fixes the bugs
@Heoz commented on GitHub (Jul 22, 2014):
Jpcsp had this problem they made software renderer which fixed floor problems idk why this game can't work normally probably one of the best games on psp :O
@CurdledSteak commented on GitHub (Jul 24, 2014):
It still doesn't work. Now 0.9.9 is out and still. The only way it work is software rendering. But it makes too slow. But hope this could be fix
@Heoz commented on GitHub (Jul 24, 2014):
It can be fixed because when you enter a lobby or whatever the room where you choose missions is floor is normal there on OpenGL
@CurdledSteak commented on GitHub (Jul 24, 2014):
But when doing a mission like Plain ls overlord. Fighting D regon. Or the enmimes you can't see them or anything. So yea its pretty hard to fight people you can't see! So I hope 0.9.1 will fix this problem.
@Heoz commented on GitHub (Jul 25, 2014):
Maybe i am crazy but you wrote 0.9.1 version it's 0.9.9 new one :O it's depht or however it's spells xD you can't see people where ground is broken or they can develop software like jpcsp xD
@CurdledSteak commented on GitHub (Jul 25, 2014):
I ment 0.9.9.1 thats what I ment
@tommor commented on GitHub (Jul 25, 2014):
Its a strange issue, in small rooms it doesnt exist because the camera is close to the wall. From what i noticed when you place the camera close to a wall you'll see everything (as shown in screenshots, in the second one camera is moved a little bit closer to wall).
@unknownbrackets commented on GitHub (Jul 25, 2014):
If you use the GE debugger in such a situation, does the depth buffer look much different? Can probably just step frame a few times and then resume, move the camera, and do that again.
-[Unknown]
@thedax commented on GitHub (Jul 25, 2014):
@unknownbrackets: Does that mean my dump from back in April was useless?
https://github.com/hrydgard/ppsspp/issues/1788#issuecomment-40887923
@tommor commented on GitHub (Jul 25, 2014):
Dont know which page of debugger should i focus on >.> but from what i remember there was no difference between the bugged and correct display when i last compared each and every entry in GE debugger :/
@unknownbrackets commented on GitHub (Jul 25, 2014):
Not useless, but I still don't know what the cause of the problem is here. But I'm wondering if the difference in what the depth buffer looks like in those two cases of the camera would help here...
It's the "Depth" tab near the preview image.
-[Unknown]
@thedax commented on GitHub (Jul 25, 2014):
The depth buffers appear to be identical whether or not the character/other graphics are incorrectly clipped or not:
When the character is not clipped incorrectly:
When it is:
I also tested in a non-corner area (e.g. a big room) with differing camera angles, and the depth buffers didn't vary there either.
Edit: For whatever reason, Github doesn't display pictures from Minus anymore. Direct links:
Correct graphics: http://i.minus.com/ibw1rkhkEPEkLW.jpg
Incorrect: http://i.minus.com/ib0zO3LGK4GrL6.jpg
@Heoz commented on GitHub (Jul 25, 2014):
Why PSP2 lost performance when stuck in ground xD where is normal graphic there is Zbuf ptr i never tried to turn camera around but if you move it around ground will break? One question in software mode ground works i read that i don't if it's true but why not compare OpenGL and Software
@CurdledSteak commented on GitHub (Jul 25, 2014):
The software mode cleans up all the bugs but its super slow. If there was too add that to buff renendering then we would make it fix. What ever is in software needs too be added to some that relates to that program.
@CurdledSteak commented on GitHub (Jul 25, 2014):
The software mode cleans up all the bugs but its super slow. If there was a way too add that to buff renendering then we would make it fix. What ever is in software needs too be added to something that relates to that program.
@tommor commented on GitHub (Jul 25, 2014):
@CurdledSteak You can edit your posts, no need to double post to fix spelling ;p
Its not that easy like "adding what works from software to OpenGL rendering", both modes use completely different coding and alghoritms to make "the magic" that makes them render stuff ^^
@CurdledSteak commented on GitHub (Jul 25, 2014):
Okay I tried re adding it but it didn't work. So yea or even make the software rendering a lot faster.
@tommor commented on GitHub (Jul 25, 2014):
@unknownbrackets Im grasping at straws here but maybe the issue here is inverted Z axis? Phantasy Star Portable 2 may have some build-in advanced face culling that make things unseeable? Its either this or like in the post from 11 Dec 2013 incorrect depth value calculation.
@Heoz commented on GitHub (Jul 25, 2014):
Hey guys try to implement triangle clipping or something like that http://www.bcu.ac.uk/cmsproxyimage?path=/_media/img/nti/gamer_camp/blog_postings/projectionspaceclipping.jpg and multiplayer missions only loading can't enter the mission xD
@CurdledSteak commented on GitHub (Jul 25, 2014):
Is there way to follow the dept on the first phantasy star portable. Because that one works a little bit. Everything with dept is find on that one. I wonder if you can just copy that code and just put it onto the second one.
@tommor commented on GitHub (Jul 25, 2014):
@CurdledSteak Just because its made by same company doesnt mean it works the same, too lazy to explain in detail but think that psp1 and psp2 are completely unrelated games.
@Heoz
The idea seems interesting but the issue here seems different, if it were what you show (before fix which ppsspp doesnt have, if polygon goes out of display bounds, dont display poly) we would see kind of staged "dissapearing" instead of smooth one like we have (sections of body would dissapear corresponding to poly placement). On the side note, dont know if it all is correct but thats how i understand it (based on 3 years programming uni and 3,5 years computer graphics uni).
@CurdledSteak commented on GitHub (Jul 25, 2014):
Okay I understand. I was just wondering thats all.
@Heoz commented on GitHub (Jul 25, 2014):
You are both wrong trust me Phantasy 1 is not same as 2 you gave opinion but idea is correct for this problem since you pass through the ground and then npc dissappear from the sight
Zbuf ptr: 08000 appears on normal screen while on glitch screen no code appeared :D
@CurdledSteak commented on GitHub (Jul 26, 2014):
If thats the truth then we go to find a ssolution to this problem
@tommor commented on GitHub (Jul 27, 2014):
Zbuf ptr: 08000 shows and disappears all the time no matter if the rendering is correct or bugged.
@CurdledSteak commented on GitHub (Jul 27, 2014):
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 commented on GitHub (Jul 27, 2014):
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 commented on GitHub (Jul 27, 2014):
Alright I just want this game to work.
@pinguallyj commented on GitHub (Jul 28, 2014):
Draw distance also appear as problem in some games too, but only with enemy sprites.
@Heoz commented on GitHub (Jul 28, 2014):
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 commented on GitHub (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 commented on GitHub (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 commented on GitHub (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 commented on GitHub (Jul 30, 2014):
Okay I just wonder when they would check this out.
@thedax commented on GitHub (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.
@thedax commented on GitHub (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 commented on GitHub (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 https://github.com/hrydgard/ppsspp/issues/6961).
@unknownbrackets commented on GitHub (Jan 3, 2016):
So, just to clarify and summarize what's going on here, at least from what I can tell.
src > dstdepth tests are simply failing; they are why things aren't drawing.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 commented on GitHub (Jan 6, 2016):
Some light flicker instead
the 4 and 5 picture in the top post still happen.
@unknownbrackets commented on GitHub (Jan 6, 2016):
I'll reopen for the flicker. But, picture 4 and 5 may simply be a render resolution issue.
-[Unknown]
@unknownbrackets commented on GitHub (Jan 18, 2016):
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 commented on GitHub (Jan 18, 2016):
The person seems brighter in software rendering.
If the savestate helps.(jpg to 7z)
@unknownbrackets commented on GitHub (Jan 18, 2016):
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 commented on GitHub (Jan 18, 2016):
So, on a PSP-2000, using a US region game, the following notes:
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 commented on GitHub (Jan 18, 2016):
Yes, looks fine under 1x
@thedax commented on GitHub (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 commented on GitHub (Sep 7, 2018):
Probably means that the "accurate depth" path used on the other backends is doing depth correctly in this case.
-[Unknown]
@unknownbrackets commented on GitHub (Nov 21, 2022):
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]