This commit changes the default value of Fast Texture Sampling to true, and also moves the setting that controls it to the experimental section of the advanced tab. This is its own commit so that it can be easily reverted when we want to default to Manual Texture Sampling.
Co-authored-by: JosJuice <josjuice@gmail.com>
Specifically, when using Manual Texture Sampling, if textures sizes don't match the size the game specifies, things previously broke. That can happen with custom textures, and also with scaled EFB copies at non-native IRs. It breaks most obviously by not scaling the texture coordinates (so only part of the texture shows up), but the hardware wrapping functionality also assumes texture sizes are a power of 2 (or else it will behave weirdly in a way that matches how hardware behaves weirdly). The fix is to provide alternative texture wrapping logic when custom texture sizes are possible.
Note that both GLSL and HLSL provide a fwidth (fragment width) function defined as `fwidth(p) = abs(dFdx(p)) + abs(dFdy(p))`. However, it's easy enough to implement this ourselves (and it makes the code a bit more obvious).
The benefit to exposing this over the raw BP state is that adjustments Dolphin makes, such as LOD biases from arbitrary mipmap detection, will work properly.
Gets rid some uses of the deprecated LocalBroadcastManager.
One note about the changes in GameFileCacheManager itself:
The change from compareAndSet to getValue followed by
setValue is actually safe, because startLoad and startRescan
only run from the main thread, and only the main thread ever
sets the flags to true. So it's impossible for any other thread
to change the flag in between the getValue and the setValue.
The past few Android releases have been adding restrictions
to what services are allowed to do, for the sake of stopping
services from using up too much battery in the background.
The IntentService class, which GameFileCacheService uses,
was even deprecated in Android 11 in light of this.
Typically, the reason why you would want use a service instead of
using a simple thread or some other concurrency mechanism from the
Java standard library is if you want to be able to run code in the
background while the user isn't using your app. This isn't actually
something we care about for GameFileCacheService -- if Android wants
to kill Dolphin there's no reason to keep GameFileCacheService
running -- so let's make it not be a service.
I'm changing this mainly for the sake of future proofing, but there
is one immediate (minor) benefit: Previously, if you tried to launch
Dolphin from Android Studio while your phone was locked, the whole
app would fail to launch because launching GameFileCacheService
wasn't allowed because Dolphin wasn't considered a foreground app.
Same problem as 658eed4... Except instead of just making the
comments use #, I'm actually removing some of the codes entirely
because they are of questionable value.
Should fix https://bugs.dolphin-emu.org/issues/12737.
This game requires emulating the Fifo Pipeline or have Single Core be
able to read ahead in the Fifo. Because Single Core currently processes
things in a serialized manner, this game will not run regardless of
CPU/GPU timing hacks.
These messages apply to the User directory regardless of
whether it's global or local, so we shouldn't specify "global".
Also changing "directory" to "folder", just for consistency
with "GC folder" in the same sentence.
This should make C++20 and std::filesystem work. (Not that
we really can use std::filesystem much on Android since
it doesn't work with scoped storage...)
