Normally, Dolphin APKs have a lib folder that contains two subfolders:
arm64-v8a and x86_64. Both contain a libmain.so file, and arm64-v8a also
contains additional .so files for libadrenotools.
When we added netplay support for Android, we brought in Jetpack Compose
as a dependency, which in turn made libandroidx.graphics.path.so be
included in Dolphin APKs. Unfortunately, this .so file was included not
only for arm64-v8a and x86_64, but also for armeabi-v7a and x86. This
made Dolphin installable on devices that use one of these older ABIs,
but because libmain.so is missing, trying to start Dolphin on such a
device results in an instant crash. We have gotten a number of Google
Play reviews from armeabi-v7a users complaining about this crash.
This fixes the problem by setting abiFilters under ndk instead of under
cmake, as documented at https://developer.android.com/ndk/guides/abis.
When calling CreateDirectory for /wfs, we were passing a UID of 19,
because that is the UID /wfs is supposed to have. However,
CreateDirectory returns AccessDenied if we try to create a directory in
the root using a UID other than 0.
To fix this, let's use UID 0 to create the directory, and then change
the UID and GID afterwards using SetMetadata. This is what the ESCore
constructor does, which is the piece of code that normally creates /wfs.
When TASing, we savestate not just /tmp but also /. The code that was
added in d35fe1b didn't handle recreating / correctly.
This commit fixes the problem by skipping recreating /, which is fine
since it always exists.
200e26c added controller handling to MovieConfigLayerLoader's
LoadFromDTM but not SaveToDTM. This caused a regression. When starting a
new input recording, MovieManager::BeginRecordingInput calls SaveToDTM,
which doesn't set the controller values in the DTM header to anything.
Then it loads the newly created movie config layer, causing LoadFromDTM
to be called, which in turn causes zeroed out controller values to be
loaded from the DTM header. This leaves the player with all controllers
set to None, making it impossible to control the game.
To fix this, let's move the saving of controllers from
MovieManager::SaveRecording to ConfigLoaders::SaveToDTM.
This game contains a special episode of the Pokémon anime as an FMV.
When playing it, if only a tiny part of the image has changed between
frames, Dolphin's texture hashing can fail to notice that anything
changed, or it can notice that the chroma changed but not the luma, or
vice versa.
512 samples reduces the problem but doesn't get rid of it entirely, but
with 2048 I'm unable to see the problem.
This makes Android players show up as "Android" instead of "Lin".
(This is only visible in DolphinQt, not in the Android GUI.)
I'm also unabbreviating all the existing operating system names:
* Win -> Windows
* Mac -> macOS
* Lin -> Linux
We already had code to close open host files when reading or writing a
savestate, but due to d35fe1b we also need to close open guest files
when reading a savestate, otherwise DoStateRead fails to delete them.
I was considering an alternative solution where instead of copying and
clearing m_handles, we just set `handle.opened = false;` for each handle
before reading a savestate (but not before writing a savestate).
However, this wouldn't solve the problem of DoStateWriteOrMeasure's
calls to OpenFile failing due to all handles being open. I'm not aware
of any games that have that many handles open, though.
We already had code to close open host files when reading or writing a
savestate, but due to d35fe1b we also need to close open guest files
when reading a savestate, otherwise DoStateRead fails to delete them.
I was considering an alternative solution where instead of copying and
clearing m_handles, we just set `handle.opened = false;` for each handle
before reading a savestate (but not before writing a savestate).
However, this wouldn't solve the problem of DoStateWriteOrMeasure's
calls to OpenFile failing due to all handles being open. I'm not aware
of any games that have that many handles open, though.
We were registering the hotplug callback when starting the thread, but
deregistering it when shutting down GCAdapter as a whole. Because the
thread can start and stop potentially many times before GCAdapter shuts
down, this led to callbacks being registered when we already have
callbacks. On Android, this was making Dolphin's Kotlin code for
registering the callback throw an IllegalStateException.
To fix this, deregister the callback when stopping the thread.
The ifdef made it so this was never called on Android, but we do want it
to be called on Android.
There are ifdefs inside the function implementation but not around the
function declaration or definition, so there's no need for ifdefs when
calling it.
Previously we would vibrate for 100 ms on every vibration, which was
especially annoying if a game was doing a bunch of vibrations that were
supposed to be much shorter than that. Now we tell Android to vibrate
for 10 s, then cancel the vibration as soon as the game turns the
vibration off.
This lets rumble work even if the user has turned off the Android
setting Sound and vibration > Vibration and haptics > Interactive
haptics > Touch feedback. Rumble can still be disabled through Dolphin's
controller bindings and through in-game settings (GameCube) or SYSCONF
(Wii).
fb4ff3e put all the code for the show internal resolution setting right
next to the code for the show FPS setting, presumably because an earlier
version of that commit had them next to each other in the GUI. It makes
more conceptual sense to put the code next to the code for the show
statistics settings, matching what the GUI looks like now.
fb4ff3e added a statistics option to show the internal resolution, but
it just showed the total size of the EFB (which is always 640x528) times
the IR scale, so it didn't convey any useful information.
This commit instead makes the option use the size of the last XFB copy
(not multiplied by the IR scale), which changes based on the game's
rendering resolution.
We don't need to see Compose previews when making a release build, but
androidx.compose.ui.tooling.preview.Preview is referenced in the source
code nonetheless, so the build system needs to know what it is.
Now SerialInterfaceManager::UpdateDevices reads the configured SI
devices directly from Config instead.
The main reason why I wanted to do this is so that Android can change SI
devices while emulation is running. (Android didn't have the code for
calling ChangeDevice.) But when implementing the change, I noticed that
NetPlay and Movie were using ChangeDevice as a way of overriding the SI
devices configured by the user. Replacing this ended up making the change
larger than I first anticipated.
For Wii Remotes, there was no equivalent to ChangeDevice, so NetPlay and
Movie were using Config::SetCurrent to override the Wii Remote source
configured by the user. If we can use the config system to override Wii
Remote sources, why not do the same for SI devices? This commit makes
NetPlay and Movie set SI devices and Wii Remote sources in the NetPlay
and Movie config layers, as that is the conceptually appropriate place
to do it.
As far as I can tell, the old Movie code for overriding SI devices and
Wii Remote sources didn't actually work. This new code does. I didn't
investigate exactly why it didn't work, but maybe it's because loading
a movie happens before emulation actually starts.
This fixes https://bugs.dolphin-emu.org/issues/14076. The issue report
more or less already says it all, but to provide a shorter summary:
We were fetching a list of vibrator IDs, but instead of passing the
vibrator ID to the vibrator manager, we passed the index of the ID in
the list. This happened to work fine on many devices, including all
devices that use DolphinVibratorManagerCompat, due to the only Vibrator
having both an index and ID of 0. But on some devices, it failed due to
the ID of the Vibrator being 1.
This fix makes us correctly pass the ID to the vibrator manager. We
still use indices in controller INI files, both for compatibility with
the controller mappings shipped with Dolphin (which use index 0) and for
backwards compatibility with older controller INI files.
We had some code in VolumeVerifier to catch the error message that
Redump.org used to show when trying to access the Wii datfile without
logging in. This restriction was removed from Redump.org around the
start of 2022, and the code has been unnecessary ever since.
When we added the RetroAchievements integration, we had a discussion
about whether sending version information in the user agent was fine
from a privacy standpoint. We reached the conclusion that it was okay,
but it was conditional on the website having a privacy policy. Neither
incarnation of Redump has that, and Redump also never asked us to send
version information like RetroAchievements did, so let's use a user
agent that just says "Dolphin" when connecting to Redump.
All the staff of Redump (except the absentee sysadmin) have decided to
start a new version of the website at redump.info. It has every disc
from the old site, it has HTTPS, it isn't buckling under the load of AI
scrapers, and moving forward, all adding and verifying of discs is going
to be happening on the new website only. Let's move over.
I've taken the unusual step of updating the translation files manually.
This is because we're very close to a release and because the change is
simple enough that I feel confident about making the change to languages
I don't speak. (I double checked that the Korean translation doesn't
ever follow "Redump.org" by a particle that has a different form
depending on whether there's a final consonant.)
JosJuice