This is a correction for 0cab1731d6 (part of #14665), where it was
overlooked that the condition to enable the RAM override was flawed: if
the user had enabled the emulated memory size override in Dolphin, but
the running game did not define a simulated memory size greater than the
retail memory size, the RAM override in IOS was wrongly misconfigured,
causing issues with Wii games.
Test plan:
- Launch Dolphin.
- In the **Settings > Advanced** section, tick the **Enable Emulated
Memory Size Override** check box, and set the maximum memory size for
both **MEM1** and **MEM2** (i.e. 64 MiB and 128 MiB respectively).
- Play any Wii game (e.g. _Mario Kart Wii_ (RMCE01)).
**Without** the patch, the emulator will hit an invalid read from
`0x83FEE78C` at `0x8019FE6C`:
<img alt="Invalid read when starting Wii game after having enabled the emulated memory override in Dolphin" title="Invalid read when starting Wii game after having enabled the emulated memory override in Dolphin" src="https://github.com/user-attachments/assets/1777485e-a421-4303-8d3d-dd49f1aaa9bf" />
**With** the patch, the emulator can execute the game as usual.
For some reason, #14738 removed the headers and allowed return codes which broke using the Netplay index for users.
Also, bools converted to a string using std::to_string would become 0/1, while fmt::format by default turns them into false/true, which also broke the index.
This reverts commit e4349ae179.
The 0x prefix is included in the characters count (unlike e.g. in Rust
where there is no 0x prefix), so that commit was wrong. Sorry about
that!
Fixes regression introduced in #14842.
Dolphin would previously crash while accessing &buffer[got], as if we
were trying to access that element instead of just obtaining a pointer
to it. The proper solution is to obtain a pointer to the first element,
and only add the offset we want to get the range.
Here is the printed message:
/usr/include/c++/16/array:210: constexpr std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator[](size_type) [with _Tp = char; long unsigned int _Nm = 128; reference = char&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
The stack trace originates from:
Source/Core/Core/HW/EXI/EXI_DeviceGecko.cpp:139
Large anonymous mappings are split into 128 MB chunks. Without MAP_MEM_VM_SHARE,
mach_make_memory_entry_64 will only return an entry spanning the first chunk.
Attempting to map through that entry will fail if it extends beyond the 128 MB
boundary, which can happen when the sizes of MEM1/MEM2 are overridden.
TypedArray doesn't implement AutoCloseable on older devices so .use{} caused a crash.
It turned out the special handling for background colours was unnecessary anyway.
SDL 3 has more misc buttons for "additional controller buttons" (e.g. left/right trigger clicks on a GameCube controller, or for the second touchpad click on the Steam Controller) which use these additional named Misc buttons. Taken from [SDL_GamepadButton](https://wiki.libsdl.org/SDL3/SDL_GamepadButton)
- Switch from ActivityResultContracts.GetContent() to OpenDocument()
which restores ACTION_OPEN_DOCUMENT behavior, granting write access
to file descriptors opened in C++ via ContentHandler.openFd().
- Replace unsafe force-unwraps (!!) in EmulationActivity with null checks.
- Improve the column measurement logic so it updates the column width when text changes.
- Use matchParentSize on the clickable target in OutlinedBox so that it is clickable when the OutlinedBox contains contents with dynamic height.
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 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
Independently spotted by both @Dentomologist and me while reviewing
PR #14805
The previous limit was correct for valid VPBs, but an invalid VPB
controlled by a malicious game could contain a non-fractional value
in current_pos_frac, which would allow writing an extra 15 samples
(30 bytes) into the stack. With AFC encoding, this is rounded up to 16
samples, but with much less control over which bytes are written.
Maybe we should be doing some validation, or bounds checking, but I'm
pretty sure this issue was copied from the original ucode, and we kinda
want to stay compatible.
The simpler fix is to just increase the size of raw_input_samples.
I've checked other code paths, and 0x514 samples seems to be the limit.
