Update Android dependencies and build tools to their latest available versions.
Rename the GameCube save magic constant to avoid a collision with the NDK 30 ARM64 signal context header.
Dolphin now uses the simulated memory size defined in `bi2.bin` to
adjust the memory size in the emulated console automatically.
If **Enable Emulated Memory Size Override** has been enabled by the
user, the fixed memory size specified for **MEM1** and **MEM2** are
still used as they were before.
Most retail games do not define the simulated memory size (Wii or
Triforce games), or define it to a value that matches the default 24 MiB
(GameCube games), so, in the general case, there is no behavior change.
One game that sets the simulated memory to a non-default value is the
debug build of _Mario Kart: Double Dash!!_, where the value is set to
48 MiB.
This enhancement is focused mainly to the modding community. Prior to
these changes, modded games with extended memory requirements would
fail to launch in Dolphin [with no indication of what the problem is] if
the user failed to set the emulated memory override to the correct
value. Now, modding tools can specify the simulated memory size in the
`bi2.bin` file to produce extended games that _just work_ in Dolphin,
without cumbersome instructions that can be overlooked by the user.
This is the 32-bit unsigned integer that is seen at offset `0x04` in the
`bi2.bin` file.
The intent is to study what games define values that departure from the
norm. Common values are 0 MiB (Wii games) and 24 MiB (GameCube games),
with some debug and demo builds featuring 48 MiB (e.g. the debug build
of _Mario Kart: Double Dash!!_).
Some of the speed hacks were not approved for RetroAchievements, meaning that users had to choose between not getting hardcore achievements, or having poor performance.
Also, renamed the instances of `$Limit internal FPS to VPS (improves performance)` to `$Limit internal frame rate (speed hack)` for consistency. They are enabled by default, so unless the user disabled them, it won't break the configuration.
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.
Example:
```
nand. r1, r2, r3
```
Assuming that none of these registers will be used again:
- Before #14278, all of them would be flushed on both sides of the branch.
- After #14278, r2 and r3 would have been flushed earlier, but r1 won't.
- With this, r1 is flushed in ComputeRC.
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.
These changes originate from testing the behaviour of the PI registers
in Linux on my Wii.
I started by testing the masks, writing 0xFFFF_FFFF to the registers on
the Wii, and then got told about their value on a GameCube, and then
figured out most of the registers through a discussion with Extrems.
Found out when attempting to make a speed hack to help Dolphin detect an idle loop. The inserted `nop` was preventing it from considering it an idle loop.
This makes us savestate the NAND using the same APIs the guest uses
instead of directly touching the host files. This solves several
problems:
* If the user loaded a malicious savestate, it could use path traversal
to overwrite arbitrary files on the host file system. (Reported by
MrSynAckster.)
* Metadata (UID, GID, attribute, modes) wasn't being savestated.
* NAND redirects weren't handled, except for NAND redirects at the root
of where the savestate was being done. (This only possibly matters if
TASing a Riivolution patch. The root of the savestate is at /tmp when
not TASing, and the only case where we do a NAND redirect is inside
/title if requested by a Riivolution patch.)
The conditions were in reverse order (maybe someone was reading the
PowerPC manual and forgot about IBM's bit numbering), and additionally
the two conditions for unsigned comparison were wrong.
Fixes https://bugs.dolphin-emu.org/issues/14054.
