In a few places in Dolphin, we're using BottomSheetDialogFragments.
These unhelpfully tend to start out in a "collapsed" state when in
landscape mode (presumably depending on factors like screen size). The
user then has to manually expand them before they can meaningfully
interact with them.
We've been automatically setting BottomSheetDialogFragments to the
expanded state if the device Dolphin is running on doesn't support
touch, since with d-pad navigation it's impossible to expand these
sheets. But I think we should set them to expanded on devices that
support touch too. I haven't encountered a single case where you can do
anything useful with any of Dolphin's BottomSheetDialogFragments while
they're collapsed, so the user always has to expand sheets manually if
they start out collapsed. And just because a device supports touch
doesn't necessarily mean you're interacting with it through the touch
screen right now - you could be using a gamepad, for instance.
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 9d9b6d8 changed our target SDK version to Android 16, it made
Android 16 stop calling onBackPressed and stop delivering KEYCODE_BACK
events. Dolphin's code isn't ready for that yet.
Android lets us opt out of this new behavior for now, so let's do so.
But the opt-out will presumably stop working once we start targeting
Android 17, so we're going to have to update Dolphin's code within the
next one or two years to support the replacement API.
For thread safety, we shouldn't return any pointers or references that
can be used to mutate the state of the PPCSymbolDB. This should be the
final part of making PPCSymbolDB thread safe unless I've missed
something.
9395238 added locking in some PPCSymbolDB functions that access member
variables, but far from all. To ensure thread safety, this commit adds
the missing locking.
9395238 added a mutex to PPCSymbolDB, and made functions return with an
"empty" result if called while the mutex is locked. This new behavior
has the potential to affect not only less important call sites like the
symbol printing mentioned in a comment, but also the JIT deciding if it
should HLE a function.
A later commit in this pull request decreases the amount of lock
contention, reducing the performance impact of this commit.
This lets us get rid of the Reset call in ProcessInputPayload, which was
causing us some threading headaches (see 74ed5e5532). Instead we handle
disconnection in the same way as the libusb implementation does.
We can register a BroadcastReceiver to have Android tell us when a GC
adapter gets connected instead of having a loop where we continuously
call SleepCurrentThread(1000) and poll the current status. When waiting
for a GC adapter to connect, this both reduces power usage and improves
responsiveness.
Note that I made openAdapter get the UsbDevice that's been stored by the
hotplug code instead of having openAdapter find the UsbDevice on its own
like before. This is only because I want to ensure that the UsbDevice
being tracked for disconnection is the same as the UsbDevice actually
being used, in case the user has multiple adapters connected.
Aims to fix https://bugs.dolphin-emu.org/issues/13686.
I'm using a less efficient approach for Jit64 than for JitArm64. In
JitArm64, I'm flushing in the slow access code, but in Jit64, I'm
flushing before the split between the slow access code and the fast
access code, because Jit64 doesn't keep register mappings around for
when it's time to emit the slow access code. But the flushing code is
only emitted when there are memory breakpoints with conditions, so I'd
say that this is a performance loss we can live with.
The next commit will add another piece of code that depends on this
assumption that we've been making. Good opportunity to document it.
In practice, all callers of EmitBackpatchRoutine are locking X30.
When Android sends Dolphin to the background, emulation *must* pause,
otherwise emulation continues running and continues outputting audio to
the user. RetroAchievements mustn't be allowed to override it.
The SetDisc function calls AchievementManager::LoadGame with the game's
volume. Calling AchievementManager::LoadGame again afterwards with
nullptr prevents RetroAchievements from working.
Instead of creating many 128 KiB mappings, we can create a few large
mappings. On my Windows PC, this speeds up GameCube (FakeVMEM) game boot
times by about 200 ms and Wii game boot times by about 60 ms. Loading
savestates is also faster, by about 45 ms for GameCube (FakeVMEM) games
and 5 ms for Wii games. The impact is presumably smaller on other OSes
because Windows is particularly slow at creating mappings.
Without this, there was a bug where if you turned the device's screen
off and on again while in the advanced mapping dialog, the input
indicators would stop updating. This is because turning the screen on
again causes devices to refresh, which causes all devices to be
recreated, leaving the AdvancedMappingControlViewHolders stuck
referencing controls belonging to devices that are no longer being
updated.
This makes sure view holders get proper widths when they use
layout_width="match_parent". This becomes quite noticeable for
AdvancedMappingControlAdapter in the next commit, but I'm also
making the change for other adapters while I'm at it.
Google Play is now blocking distribution for Android TV unless we
explicitly set the android.hardware.microphone hardware feature as
android:required="false", because it's inferring
android.hardware.microphone from the android.permission.RECORD_AUDIO we
added for Wii Speak emulation, with android:required defaulting to true.
I was under the belief that setting android:required="false" on
android.permission.RECORD_AUDIO would solve this, but looking closer at
the definition of <uses-permission>, it doesn't actually support
android:required attributes, so that presumably has no effect.
Google Play is now blocking distribution for Android TV unless we
explicitly set the android.hardware.microphone hardware feature as
android:required="false", because it's inferring
android.hardware.microphone from the android.permission.RECORD_AUDIO we
added for Wii Speak emulation, with android:required defaulting to true.
I was under the belief that setting android:required="false" on
android.permission.RECORD_AUDIO would solve this, but looking closer at
the definition of <uses-permission>, it doesn't actually support
android:required attributes, so that presumably has no effect.
This can reduce audio latency according to
https://developer.android.com/ndk/guides/audio/opensl/opensl-prog-notes#perform.
Previously we were using the hardcoded values of 48000 Hz and 256 frames
per buffer. The sample rate we use with this change is 48000 Hz on all
devices I'm aware of, but the buffer size does vary across devices.
Terminology note: The old code used the term "sample" to refer to what
Android refers to as a "frame". "Frame" is a clearer term to use for
this, so I've changed OpenSLESStream's terminology. One frame consists
of one sample per channel.
Not sure if we're ever going to want to have more than one of these at
the same time, but these global variables are a code smell nonetheless.
I'm also deleting the existing member variables because they were
unused.
If you already have a mapping set in the advanced mapping dialog and
want to change it, the easiest way to do it is to press Clear and then
select the new mapping from the list. But pressing Clear causes the
dialog to close, forcing you to open it again, which is inconvenient.
This commit makes it so the Clear button doesn't close the dialog.
On real hardware, stswi and stswx don't trigger any of the special
behavior for uncached unaligned writes that was implemented in 543ed8a.
This is confirmed by a hwtest (a new commit in
https://github.com/dolphin-emu/hwtests/pull/42).
This change fixes Dolphin's stswi and stswx implementations so they stop
triggering the special behavior, bringing them back to the behavior they
had before 543ed8a. No games are known to be affected, but Extrems has
reported that it affects homebrew they've made.
This fixes a memory leak that would occur when the Android frontend
calls LogManager::Init more than once in order to reload settings.
Note that the log window listener is now owned by LogManager instead of
by the frontend, making it consistent with the other log listeners.
Old cruft from when the Android code was loading INI files manually.
We don't have any handling for failing to load settings anymore.
This change also updates related comments to reflect how things actually
work nowadays.
Probably a copy-paste error from layout-ldrtl/list_item_setting.xml.
This error made it so a long setting name could overlap with the
checkbox next to it if Dolphin was running with right-to-left layout.
The incorrect ID was apparently also causing the app:lintVitalRelease
build task to fail. I guess we're not running that build task, because I
only heard of this from someone building Dolphin locally.
JosJuice