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.
This was added in 0b9a72a62d38481ff08f742b2318d07f29ff5dff but became irrelevant in 70f9fc4e7526fc9cfc008a43cd33229f62be99b6 as the check is now self-explanatory due to a rejiggering of the bitfields.
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.
Unlike with Android 11, there should be no downsides to doing
this, so we might as well get this out of the way early.
The main part of the work was already done in 5a1a642.
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...)