Without clip control, OpenGL maps clip z -w..w to window depth 0..1, and the
PSP's Z 0 at z/w = -1 isn't reproduced exactly by the rasterizer (see the
previous commit). Now clip z is 0..w everywhere, which without clip control
lands in window depth 0.5..1. Z 0 is z/w = 0, exact.
Everything that writes or reads window depth directly uses 0.5 + 0.5 * depth
(ShaderLanguageDesc::depthHalfRange, DepthToWindow / DepthFromWindow): depth
clears, fragment depth writes, depth uploads, depth readbacks (including the
debugger's) and depal from depth.
Hardware clipping now only happens below -w, so a clip plane at Z 0 takes
over unless depth clamp is on, which ShaderManagerGLES passes as a min Z of
-1. The hardware clamp works in window depth and can't clamp at 0.5, so
clamping moves to the fragment shader. That shader wrote Z / 65535 against
Z / 65536 for every other draw, which broke depth ties with them; it now
writes Z / 65536.
Fixes the Burnout Dominator lens flare on macOS OpenGL. 0.5..1 costs a bit
of depth precision, which shows on a float depth buffer (ATV Offroad Fury Pro
is 6% worse here), less so on D24.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Rename LogType to Log
* Explicitly use the Log:: enum when logging. Allows for autocomplete when editing.
* Mac/ARM64 buildfix
* Do the same with the hle result log macros
* Rename the log names to mixed case while at it.
* iOS buildfix
* Qt buildfix attempt, ARM32 buildfix
I failed to notice that when doing the shift to apply the "texel offset"
translating CLUT8 to a CLUT16 lookup, we also need to shift the mask
used to choose color components to read.
This is a partial fix for #6105 (Ratchet & Clank particles visible
through things), but there's still weird glitchiness. There's a pass
during rendering that scrambles the mini depth buffer by using a
triangle mesh. I wonder if it's trying to simulate the swizzle? But it
doesn't really look like it...
