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.
To fix the crash in input device sensor handling, we should look up
Sensors using structural equality. Unfortunately, Sensor.equals
implements referential equality, and HashMap doesn't let us provide a
custom comparator. Because the number of sensors is relatively small,
and because we have a reason to keep a sorted list of sensors around
anyway, let's switch from HashMap to ArrayList.
Currently we're showing OSD messages for unknown patches in known INI
files, but not for unknown patches in unknown INI files. I don't think
this distinction makes much sense to the user. If there's a patch the
user can't use, they probably want to be aware of that fact.
0c14b0c8a7 made Dolphin load a file from
the Sys folder the first time AchievementManager::GetInstance() is
called. Because Android calls AchievementManager::GetInstance() from
setBackgroundExecutionAllowedNative, this had two negative consequences
on Android:
1. The first time setBackgroundExecutionAllowedNative gets called is
often before directory initialization is done. Getting the path of
the Sys folder before directory initialization is done causes a crash.
2. setBackgroundExecutionAllowedNative is called from the GUI thread,
and we don't want file I/O on the GUI thread for performance reasons.
This change makes us load the data from the Sys folder the first time
the data is needed instead. This also saves us from having to load the
data at all when hardcore mode is inactive.
We mustn't use m_system when it is nullptr. This was causing Dolphin to
crash on Android whenever an activity was recreated or resumed while
emulation is running, which is super common.
By request from delroth, I changed the name of our Transifex
organization so it's named after the Dolphin project rather than after
him. This broke old links and the .tx/config file.
This reverts commit 72cf2bdb87.
SYSCONF settings are getting cleared when they shouldn't be. Let's
revert the change until I get proper time to figure out why it's broken.
Some pieces of code are calling IsRunning because there's some
particular action that only makes sense when emulation is running, for
instance showing the state of the emulated CPU. IsRunning is appropriate
to use for this. Then there are pieces of code that are calling
IsRunning because there's some particular thing they must avoid doing
e.g. when the CPU thread is running or IOS is running. IsRunning isn't
quite appropriate for this. Such code should also be checking for the
states Starting and Stopping. Keep in mind that:
* When the state is Starting, the state can asynchronously change to
Running at any time.
* When we try to stop the core, the state gets set to Stopping before we
take any action to actually stop things.
This commit adds a new method Core::IsUninitialized, and changes all
callers of IsRunning and GetState that look to me like they should be
changed.
Core::GetState reads from four different pieces of state: s_is_stopping,
s_hardware_initialized, s_is_booting, and CPUManager::IsStepping.
I'm keeping that last one as is for now because there's code in Dolphin
that sets it directly, but we can unify the other three to make things
easier to reason about.
This commit also gets rid of s_is_started. This was previously used in
Core::IsRunningAndStarted to ensure true wouldn't be returned until the
CPU thread was started, but it wasn't used in Core::GetState, so
Core::GetState would happily return State::Running after we had
initialized the hardware but before we had initialized the CPU thread.
As far as I know, there are no callers that have any real need to know
whether the boot process is currently initializing the hardware or the
CPU thread. Perhaps once upon a time there was a desire to make the
apploader debuggable, but a long time has passed without anyone stepping
up to implement it, and the way CBoot::RunApploader is implemented makes
it rather difficult. So this commit makes all the functions in Core.cpp
consider the core to still be starting until the CPU thread is started.
We currently have 32 different binaries containing unit tests. At least
when I build for Android, each one takes up over 200 MiB, and linking
them all increases my incremental build times by over a minute. I'd
like to change this for the sake of my productivity and disk space.
For reference, MSBuild is already putting all tests in a single binary.
This lets us reduce the number of USE_RETRO_ACHIEVEMENTS ifdefs in the
code base, reducing visual clutter. In particular, needing an ifdef for
each call to IsHardcodeModeActive was annoying to me. This also reduces
the risk that someone writes code that accidentally fails to compile
with USE_RETRO_ACHIEVEMENTS disabled.
We could cut down on ifdefs even further by making HardcodeWarningWidget
always exist, but that would result in non-trivial code ending up in the
binary even with USE_RETRO_ACHIEVEMENTS disabled, so I'm leaving it out
of this PR. It's not a lot of code though, so I might end up revisiting
it at some point.
Right now, we assign a versionCode to each Android build of Dolphin by
counting the total number of git commits made. This has worked fine so
far, but it won't work as-is for the new release process.
Let's say we're currently on commit 20000. If we want to create a
release under the new release process, we would create a release branch,
add a new commit on it that updates the release name in CMake files and
so on, and create a tag for that commit. The Android build of this
release commit would get the version code 20001. However, the master
branch is also going to get a commit with the version code 20001 sooner
or later, and this commit would be an entirely different commit than
commit 20001 on the release branch. This isn't much of a problem for
people downloading Dolphin from dolphin-emu.org, but it's a big problem
for Google Play, as Google Play doesn't allow us to upload two builds
with the same version code.
This commit makes us calculate the Android version code in a new way:
The number of commits times two, and if the current build isn't a
release build, plus 1. (We check whether the current build is a release
build by checking whether there's a tag for the current commit.)
With this new version code scheme, the release commit described in my
example would get the version code 40002, and the master commit would
get the version code 40003. This lets us upload both corresponding
builds to Google Play, and also lets the user switch from the release
build to the development build if they would like to. (Under normal
circumstances, Android forbids installing a build with an older version
code than the currently installed build. Therefore, whether the 1 is
added for release builds or for development builds is a decision with
consequences.)
Using shifts and bit tests makes the code unnecessarily annoying to
reason about. I'm replacing it with subtracting from 3 to translate the
bit order from the PowerPC format to the usual format.
BI contains both the field and the flag (5 bits total), so we need to
shift away the 2 flag bits to get the 3 field bits. (Same as the
CRBA/CRBB handling in the code just below the BI code.)
JosJuice