This reverts to the old behavior before we started parsing mpeg headers,
that is, in 558b462 which is part of #8867.
LunaMoo has this under "HackFixVideo" in his build.
See #8991. This doesn't really "fix" that, but works around it.
* 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
Fixes#17014
Even if our depth-testing-equal heuristic believes that the game needs
lower depth resolution.
This removes some depth-fighting artifacts (that are present on the real
PSP, but nice to avoid) in Outrun, Split/Second and Cars: Race-o-Rama -
essentially reverting these to the behavior we had before the heuristic.
(The heuristic is good though - it means less compat.ini hacks going in
the other direction).
In the case of Outrun, this relies on two passes that pass exactly the
same vertex coordinates twice resulting in the exact same final
geometry. This is actually guaranteed by the spec if the vertex math is
exactly the same and "invariant" is set on the position output, though
I guess you never know.. Haven't seen any issues at least.
Also sneak in disabling some validation messages from using extra Vulkan
validation layers other than the default.
Fixes#11442. Or at least should, I haven't tested this, just followed the
discussion in the issue.
According to this issue, this is a game bug that happens on real hardware
too, due to a lousy job porting the game to the PSP, most likely, which has
different ADSR (note envelope) behavior.
It breaks or just makes things look terrible in these games, so no
reason to allow it.
An alternative for this would be to remove the option entirely, and only
use it though the ForceLowerResolutionForEffectsOn flag instead.
Seems the game might not handle the case of confirm button being set to
cross properly, so force it to circle if this game is running.
Fixes#15663 (hopefully..)
* OpenXR - Compat GTA games
* OpenXR - Compat 0-9 games
* OpenXR - Compat A games
* OpenXR - Compat B games part 1
* OpenXR - Compat B games part 2
* OpenXR - Compat C games part 1
* OpenXR - Compat C games part 2
* OpenXR - Compat D games
* OpenXR - Compat E games
* OpenXR - Compat F games
* OpenXR - Compat G games
* OpenXR - Compat H games
* OpenXR - Compat I games
* OpenXR - Compat J games
* OpenXR - Compat K games
* OpenXR - Compat L games
* OpenXR - Compat M games
* OpenXR - Compat N games
* OpenXR - Compat P games
* OpenXR - Compat R games
* OpenXR - Compat S games
* OpenXR - Compat T games
* OpenXR - Compat U games
* OpenXR - Compat V games
* OpenXR - Compat W games
* OpenXR - Compat games sorting out part 1
* OpenXR - Compat games sorting out part 2
* OpenXR - Compat games sorting out part 3
* OpenXR - Compat games sorting out part 4
* OpenXR - Compat games sorting out part 5
* OpenXR - Compat games sorting out part 6
* OpenXR - Compat list description
* OpenXR - Support getting compatvr.ini from filesystem
Solves the last problem with the speedometers - so we can finally say: Fixes#8509
Render-to-CLUT for speedometers renders on top of an image that just comes from the
underlying memory, so it's been drawn to the framebuffer with DrawPixels. That adds
filtering so at higher resolutions, there's some blurring of the CLUT, causing
artifacts. We can solve this two ways: either we force on lower-resolution-for-effects
for Ridge Racer games, or we use nearest filtering when doing DrawPixels of the
memory under a framebuffer. For best result, we do the latter.
(The speedometers look even better with nearest filtering, but that's a more
general issue of UI looking better that way).
This compat flag should be temporary until we've implemented
a readback-free path for CLUTs from framebuffers, both when texturing
from static textures and other framebuffers.
