In JitRegCache.cpp, the lambda predicate were replaced by a pointer to member function because ranges algorithms are able to invoke those.
In ConvertDialog.cpp, the `std::mem_fn` helper was removed because ranges algorithms are able to handle pointers to member functions as predicates.
In BoundingBox.cpp, the lambda predicate was returning the bool element unchanged, so `std::identity` was a better fit.
Makes Graphics -> Hacks -> Skip EFB Access from CPU enabled by default. Some GPU drivers stall when EFB access occurs in games where EFB is not used. Most games that require this setting set to 'true' already have this defined in their game inis.
`std::erase` is a replacement for the remove-erase idiom.
Changes to `OpenModeToAndroid` inadvertently revealed that the prior implementation had UB (potentially deleting the end iterator). This is now fixed.
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.
With 12 uses of `JoinStrings` in the codebase vs 36 uses of `fmt::join`, fmtlib's range adapter for string concatenation with delimiters is clearly the preferred option.
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.)
In a race condition, the core could shut down between the `JitInterface::GetCore` nullptr check and the `JitInterface::JitBlockLogDump` call which constructs a `CPUThreadGuard`. In this scenario, nothing horrible happens—`JitBlockLogDump` also checks for a nullptr—but it would be a failure to display the correct feedback to the user.
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.
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.
Storing the log type names in a map results in them getting re-sorted by
their keys, which doesn't quite give us the sorting we want. In
particular, the Achievements category ended up being sorted at R (for
RetroAchivements) instead of at A. Every use of the map is just
iterating through it, so there's no real reason why it has to be a map
anyway.
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.)
Enable emulator hotkeys and controller input (when that option is
enabled) when a TAS Input window has focus, as if it was the render
window instead. This allows TASers to use frame advance and the like
without having to switch the focused window or disabling Hotkeys Require
Window Focus which also picks up keypresses while other apps are active.
Cursor updates are disabled when the TAS Input window has focus, as
otherwise the Wii IR widget (and anything else controlled by the mouse)
becomes unusable. The cursor continues to work normally when the render
window has focus.
It was possible for sAlertMessageLock.notify() to be called before
sAlertMessageLock.wait(), causing Dolphin to deadlock. In particular,
this was guaranteed to happen if displayAlertMsg was called from the UI
thread while the emulation activity is being destroyed, because
runOnUiThread runs the passed-in anonymous function immediately when
called from the UI thread.
By replacing Object.wait/Object.notify with Semaphore.acquire/
Semaphore.release, it no longer matters what order the methods are
called in.
Because SettingViewHolder is used in RecyclerViews, we have to
explicitly unset STRIKE_THRU_TEXT_FLAG when we don't want it, otherwise
it might be left over from when the SettingViewHolder was representing
a different setting.
There were three distinct mechanisms for signaling symbol changes in DolphinQt: `Host::NotifyMapLoaded`, `MenuBar::NotifySymbolsUpdated`, and `CodeViewWidget::SymbolsChanged`. The behavior of these signals has been consolidated into the new `Host::PPCSymbolsUpdated` signal, which can be emitted from anywhere in DolphinQt to properly update symbols everywhere in DolphinQt.
This PR simply exposes the tapserver options in Serial Port 1 on Android. They already exist and work, but are not selectable. I've tested the tapserver options myself with Phantasy Star Online Episode I & II and they work fine.
This implements the GameCube modem adapter. This implementation is stable but not perfect; it drops frames if the receive FIFO length is exceeded. This is probably due to the unimplemented interrupt mentioned in the comments. If the tapserver end of the connection is aware of this limitation, it's easily circumvented by lowering the MTU of the link, but ideally this wouldn't be necessary.
This has been tested with a couple of different versions of Phantasy Star Online, including Episodes 1 & 2 Trial Edition. The Trial Edition is the only version of the game that supports the Modem Adapter and not the Broadband Adapter, which is what made this commit necessary in the first place.
This expands the tapserver BBA interface to be available on all platforms. tapserver itself is still macOS-only, but newserv (the PSO server) is not, and it can directly accept local and remote tapserver connections as well. This makes the tapserver interface potentially useful on all platforms.
Google Play's policies require us to tell the user the size of any large
download.
The size seems to vary by just a megabyte or two across regions in my
testing, so I'm listing a rough size for all the regions.
I'm also taking the opportunity to shorten the message to make it easier
to read.
Because the wording of the Load Wii System Menu string can change
depending on the contents of the NAND, we should update that menu item in
a method that's guaranteed to get called every time the user opens the
menu rather than one that's only guaranteed to be called once.
After reading the previous commit, you might think "hold on, what's the
difference between GetProfileName and GetProfileDirectoryName"? These
two are being used for the exact same thing - figuring out where
profiles are stored - yet they return different values for certain
controllers like GC keyboards! As far as I can tell, the existing code
has been broken for GC keyboards since they were introduced a decade
ago. The GUI (and more recently, also InputCycler) would write and read
profiles in one location, and our code for loading profiles specified in
a game INI file would read profiles in another location.
This commit gets rid of the set of values used by the game INI code in
favor of the other set. This does breaking existing setups where a
GCKey profile has been configured in a game INI, but I think the number
of working such setups is vanishingly small. The alternative would make
existing GCKey profiles go missing from the profile dropdown in the GUI,
which I think would be more disruptive. The alternative would also force
new GCKey profiles into the same directory as GCPad profiles.
This commit also fixes a regression from d6c0f8e749. The Android GUI was
using GetProfileName to figure out what key to use in the game INI,
which made it use incorrect game INI entries for GameCube controller
profiles but not Wii Remote profiles. Now the Android GUI uses
GetProfileKey for this, fixing the problem.
"When interacting with DocumentUI or the built-in Android System Internal Files Manager app and performing Create, Rename, and Delete operations, DocumentsUI will not automatically refresh the changes.
Previously, users had to manually pull down from the top to refresh the changes. This commit aims to fix this issue by automatically notifying the system that changes have occurred and triggering a requery."
