-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Implement basic depth texturing for OpenGL #14042
Conversation
What required OpenGL version to support GL_DEPTH_CLAMP? |
I believe desktop GL 3.2 or newer is enough, or that exposes the extention GL_ARB_depth_clamp . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case where we enable this, shouldn't we also enable accurate depth? Otherwise the depth values we're texturing from will be skewed and wrong in some cases.
-[Unknown]
caps_.depthClampSupported = gl_extensions.ARB_depth_clamp; | ||
|
||
// Interesting potential hack for emulating GL_DEPTH_CLAMP (use a separate varying, force depth in fragment shader): | ||
// https://stackoverflow.com/questions/5960757/how-to-emulate-gl-depth-clamp-nv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably should do this, but I'd think we might need a setting - it might make things a lot slower in some games where people might be willing to withstand weird clipping issues near the edges for speed...
In some games depending on how they draw, it might not be that big a difference I suppose.
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, will depend a lot on the GPU architectures too, changing gl_FragDepth can have between nearly none to a very large performance penalty, I believe. So a blanket enable is probably not realistic, adding that to the comment.
|
||
if (pixelFormat == GE_FORMAT_DEPTH16) { | ||
DepthScaleFactors factors = GetDepthScaleFactors(); | ||
WRITE(p, "const float z_scale = %f;\n", factors.scale); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, I'd recommend factors.scale * 1.0f / 65535.0f
. Then below it'd just be color = (color - z_offset) * z_scale;
right?
These values wouldn't vary, so we could avoid the formula when offset is 0 and scale is 65535, which will be true if clamp is enabled.
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I don't see how dividing by 65535 helps here. Then we'd just have to scale it up again to turn it into an integer index later...
Indeed, the values are constant, but I'm thinking that we might be able to also support this when we use the depth rescaling/offset stuff to simulate clamping, in some cases, so want to keep the flexibility. The distortion you mentioned earlier kind of prevents that though I guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I missed the other code below that wants it as an int. This doesn't already work with the 1/4 scale thing?
Also in that case, how does WRITE(p, " float color = tex.Sample(texSamp, v_texcoord0).x;\n");
work with color.x
later?
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure honestly if it works correctly with the 1/4 scale. But hopefully it does.
You can take .x of a float in HLSL, it's effectively a vec1. However it does look confusing...
Any android devices that supports GL_EXT_depth_clamp? |
@Panderner Maybe the nvidia shield android tv |
I think many mali GPUs support |
Not according to gpuinfo: http://opengles.gpuinfo.org/listreports.php?extension=GL_EXT_depth_clamp |
@hrydgard This pr only help desktop opengl but not android without GL_EXT_depth_clamp? |
Should make support for depth texturing quite easy. Unfortunately, this extension does not exist on OpenGL ES. There we'll have to use ugly tricks with gl_FragDepth if we want this.
253f354
to
90460df
Compare
Rebased on master again, surprisingly no conflicts. And no, this won't help on GLES unfortunately, only desktop-gl for now. And in response to a previous comment, this does enable accurate-depth when the required extension is available, so the depth buffer scaling issues and such should not apply. I do think this might be ready for merge as-is. |
Eh, let's just try it. |
if (!gstate_c.Supports(GPU_SUPPORTS_32BIT_INT_FSHADER)) { | ||
useShaderDepal = false; | ||
depth = false; // Can't support this |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, is it better to use the color part of the framebuf or just ignore the attachment I wonder?
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The color part probably isn't usually very meaningful when you're trying to read the depth, so ignoring is probably better... unfortunately currently no good way to bind an empty texture here? Hm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the better thing would be a Supports flag and handle this when choosing candidates... (maybe we already even do that?)
-[Unknown]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think we already do...
Note: This also fixes Hokuto no Ken blackscreen issue for OpenGL for desktop systems (#7932). |
That's just because it enables depth clamp on desktop OpenGL. Accurate depth (with its "simulation" of depth clamp) would probably fix it, too. -[Unknown] |
Dug up a couple of old branches and put them together and got it working.
Only works on desktop, this currently requires GL_ARB_depth_clamp which is not really supported on mobile (there is an extension, GL_EXT_depth_clamp, but few mobile devices support it).
Need to figure out what to do about the extended Z mappings we use when either extension is not available.
Helps #6411 for OpenGL on desktop primarily, and certain other games affected by #13256
are likely working too like the fog in Harry Potter.
Let's merge after 1.11.