When opening a file dialog to set the location of a custom path, use the
corresponding user path as the starting location instead of the current
custom path.
When no custom path was set the dialog would be opened with a blank path
which causes Windows (not sure about other platforms) to open the dialog
at the same location where the last dialog was closed, or at the current
working directory if no previous dialog had been opened.
If a nonempty custom path has been set then it has also set the
corresponding user path, so the behavior in that case is unchanged.
`MaxAnisotropy = 0` is no longer the safest setting because it forces 1x
even if the game asks for more.
`ForceFiltering` was replaced by `ForceTextureFiltering` in
afe9d5b098. The one remaining occurrence
was merged later.
`ForceTextureFiltering` is an int option and shouldn't be set to False.
Just Dance 3, Just Dance: Best of, and Just Dance: Greatest Hits look
fine on AMD GPUs without manual texture sampling. On Nvidia GPUs they
have a single stripe that I think doesn't warrant forcing manual texture
sampling for everyone.
The NES games I tried worked fine with anisotropic filtering, it just
doesn't do anything.
Various games don't actually have any issue with anisotropic filtering
as long as it's not forced. The only game I could find that actually
requires the default aniso setting is Spider-Man: Shattered Dimensions.
Boogie SuperStar works fine with any texture filtering setting.
Adds `DocumentsContract.Root.FLAG_SUPPORTS_IS_CHILD` to the list of the flags in order to show up for third-party apps for easier file syncing with local/cloud file server providers
Adds `DocumentsContract.Root.FLAG_LOCAL_ONLY` to the list of the flags in order to show up for third-party apps for easier file syncing with local/cloud file server providers
The callback mechanism AchievementManager had until now only supported
one caller registering a callback, and it didn't have any
synchronization. This isn't a problem for DolphinQt, but the PR to add
Android support for RetroAchievements exposes these problems. Let's
replace it with HookableEvent, which can handle all of this.
The instruction implementations that were shifting the size by 4 would
emit an incorrect instruction when given a size of 64. The correct
implementation is to count the number of leading or trailing zeroes in
the size parameter, which is what IntLog2 does.
No callers are affected by this, as they all use sizes other than 64.
Actually, some of these instructions are even invalid with a size of 64,
but I'm changing them anyway for consistency with the others.
When dragging the selection, the mismatch between signal
(itemSelectionChanged) and data consumed (currentRow) seemed to cause
the description to lag behind by one row.
We should attempt to use not only mirrored versions of the immediate as
an ORR base, but also the immediate itself. This lets us emit certain
64-bit constants using fewer instructions.
