When I wrote 71e9766519, there was an interaction I didn't take into
account: When setting eq, SetCRFieldBit assumes that all bits in the
passed-in host register except the least significant bit are 0. But if
we use EON or ORN, all bits except the least significant bit get set to
1. This can cause eq to end up unset when it should be set.
This commit fixes the issue.
crandc is unaffected by the issue because the "1" bits get ANDed with
"0" bits from the first operand.
Note that in practice, we never have both bits_1_to_31_are_set and
negate at once, so while it looks like this commit adds an extra AND
instruction in some cases, those cases don't happen in practice, meaning
this fix shouldn't affect performance.
No games seem to use this, so this isn't useful as a performance
optimization, but it's required for correctness because the (sh == 0)
case of our implementation doesn't handle zero masks.
The read thread could call Reset, which in turn tried to join the read
thread, leading to a SIGABRT. This manifested as Dolphin consistently
crashing when disconnecting a GC adapter and having a chance of crashing
a few seconds after connecting a GC adapter.
Unlike on x64, inverting EQ or GT in SetCRFieldBit saves us one
instruction. Also unlike on x64, inverting SO or LT in GetCRFieldBit
requires an extra instruction (just like in SetCRFieldBit). Due to this,
replacing an invert in GetCRFieldBit with an invert in SetCRFieldBit
when possible is either equally good or better - never worse.
Recently we have been getting some requests to make the existing vsync
setting available in the Android GUI:
https://bugs.dolphin-emu.org/issues/13650https://forums.dolphin-emu.org/Thread-vsync-toggle-for-android
I don't quite understand why enabling the vsync setting is helpful when
Android already enforces vsync, but I guess having the option available
doesn't hurt. I'm putting the setting under Advanced, unlike in
DolphinQt, since there's no clear reason why the typical user would want
to use this setting.
This reverts the revert commit bc67fc97c3,
except for the changes in BaseConfigLoader.cpp, which caused the bug
that made us revert 72cf2bdb87. PR 12917
contains an improved change to BaseConfigLoader.cpp, which can be merged
(or rejected) independently.
A few changes have also been made based on review comments.
Dolphin has been using edge-to-edge rendering for a little while now,
but it has required a bit of manual work. Now that edge-to-edge is
becoming something expected of apps in Android 15, there's a nicer API
we can use.
Tested on Android 8, 11 and 13, with no changes in behavior noted.
So far, Dolphin hasn't been able to run on Android devices that use a
16 KiB page size. 16 KiB page sizes are a very new Android feature that
no phones have shipped with so far, so we're still compatible with the
phones that exist out there, but let's get this fixed before phones
start shipping with 16 KiB page sizes.
Because I couldn't get Android Studio's emulator to work, I haven't been
able to confirm that this change actually makes Dolphin fully compatible
with devices that use a 16 KiB page size. But I have confirmed that this
doesn't break anything on a regular 4 KiB page size device.
When we boot the core, it needs to have a valid surface to draw graphics
to. Our Kotlin code does wait for a valid surface to exist before it
calls NativeLibrary.Run, but there's a chance for the surface to be
deleted before Run locks s_surface_lock. If that happens, the core boots
without a valid surface, which presumably would cause a crash. (I
haven't been able to reproduce the problem myself.)
The description of the Speed Limit setting currently uses a lot of
complicated terms, like "emulated time" (known to many Dolphin
developers, but in my experience not known by even advanced emulator
users) and "maximum time scale" (I have never heard it before). The
meaning of "sustainable" is also unclear in context.
This commit rewords the description to be easier to understand.
Input/output tracking is intended to speed up incremental builds by
skipping a target when it doesn't need to be built. However, this seems
to be unreliable for UnitTests' AfterBuild target. Let's remove it.
It's still the case that UnitTests' AfterBuild target will be skipped if
UnitTests doesn't need to be rebuilt. (Note that UnitTests always needs
to be rebuilt if SCMRevGen changed.)
I haven't seen these problems with DolphinQt's rather similar
input/output tracking. This may be because DolphinQt's one also has the
exe file as an input/output.
Like the previous commit, but for UnitTests. This time all operating
systems were affected.
I also made UnitTests.vcxproj use the same way of copying as
DolphinQt.vcxproj, just for consistency.
For a long time now, we've had a problem where game INIs persist in
the copied Sys folder if they've been deleted from the original Sys
folder. (I still have hundreds of game INIs locally that only set
EmulationStateId, and we removed those game INIs 6 years ago. On the
buildbot, we do occasionally clear out the build directories manually,
so I'd assume it's not quite as bad there.)
This commit fixes the problem by deleting the output Sys folder before
copying the original Sys folder to the output Sys folder. This should be
a bit slower, but in my testing, the difference seems small. At least if
you have an SSD, which I really hope people have nowadays!
Operating systems other than Windows have not been touched, because:
* Android: Already explicitly deletes the output Sys folder.
* macOS: Does some magic to put the Sys folder in the app bundle, which I
will simply assume isn't affected by this problem, without testing.
* Linux: Expects the person building to manually manage the Sys folder.
JosJuice