This introduces a CMakePresets file for both Unix-likes and Windows that replace the old CMakeSettings.
It adds presets for **Debug** and **Release** profiles for both **x64** and **ARM64** architectures, as well as **Generic builds**.
Presets can be used using[ Visual Studio's built-in CMakePresets support](https://learn.microsoft.com/en-us/cpp/build/cmake-presets-vs?view=msvc-170), or [Visual Studio Code's CMake Tools](https://marketplace.visualstudio.com/items?itemName=ms-vscode.cmake-tools) extension.
They can also be used from the command line, like so:
- x64/Unix-like/Ninja:
- Configure: `cmake --preset ninja-release-x64`
- Build: `cmake --build --preset ninja-build-release-x64`
- Configure + Build: `cmake --workflow --preset ninja-release-x64`
- ARM64/Windows/Visual Studio:
- Configure: `cmake --preset visualstudio-release-arm64`
- Build: `cmake --build --preset visualstudio-build-release-arm64`
- Configure + Build: `cmake --workflow --preset visualstudio-release-arm64`
The Ninja generator is available to both Windows and Unix-likes, while the Visual Studio Generator is only available on Windows.
**Cross-compiling**
On **Windows**, the Visual Studio generator automatically takes care of everything, you just need to select an ARM64 preset.
On **Unix-likes**, to cross-compile you need to install a cross-compiler and (optionally) a sysroot of the target system.
Here is an example to compile from x64 to ARM64 with a sysroot:
- `cmake --preset ninja-release-arm64 -DCMAKE_C_COMPILER=aarch64-linux-gnu-gcc -DCMAKE_CXX_COMPILER=aarch64-linux-gnu-g++ -DCMAKE_SYSROOT=/opt/sysroots/aarch64-linux-gnu`
- `cmake --build --preset ninja-build-release-arm64`
You will need a sysroot to link against Qt, since we do not vendor it in on platforms other than Windows.
**User presets**
A `CMakeUserPresets.json` file may be created locally at the root of the project to further customize your presets.
For example, here are the user presets I used to test this PR on Arch Linux with a generic Arch Linux ARM sysroot:
```json
{
"version": 10,
"configurePresets": [
{
"name": "gcc-debug-arm64",
"inherits": "ninja-debug-arm64",
"cacheVariables": {
"CMAKE_C_COMPILER": "aarch64-linux-gnu-gcc",
"CMAKE_CXX_COMPILER": "aarch64-linux-gnu-g++",
"CMAKE_EXE_LINKER_FLAGS": "-L/opt/sysroots/ArchLinuxARM/lib",
"CMAKE_SYSROOT": "/opt/sysroots/ArchLinuxARM"
}
},
{
"name": "clang-debug-arm64",
"inherits": "ninja-debug-arm64",
"cacheVariables": {
"CMAKE_C_COMPILER": "clang",
"CMAKE_CXX_COMPILER": "clang++",
"CMAKE_C_FLAGS": "-target aarch64-linux-gnu",
"CMAKE_CXX_FLAGS": "-target aarch64-linux-gnu",
"CMAKE_SYSROOT": "/opt/sysroots/ArchLinuxARM"
}
},
{
"name": "clang-debug-x64",
"inherits": "ninja-debug-x64",
"cacheVariables": {
"CMAKE_C_COMPILER": "clang",
"CMAKE_CXX_COMPILER": "clang++"
}
}
],
"buildPresets": [
{
"name": "gcc-build-debug-arm64",
"configurePreset": "gcc-debug-arm64"
},
{
"name": "clang-build-debug-arm64",
"configurePreset": "clang-debug-arm64"
},
{
"name": "clang-build-debug-x64",
"configurePreset": "clang-debug-x64"
}
],
"workflowPresets": [
{
"name": "gcc-debug-arm64",
"steps": [
{ "type": "configure", "name": "gcc-debug-arm64" },
{ "type": "build", "name": "gcc-build-debug-arm64" }
]
},
{
"name": "clang-debug-arm64",
"steps": [
{ "type": "configure", "name": "clang-debug-arm64" },
{ "type": "build", "name": "clang-build-debug-arm64" }
]
},
{
"name": "clang-debug-x64",
"steps": [
{ "type": "configure", "name": "clang-debug-x64" },
{ "type": "build", "name": "clang-build-debug-x64" }
]
}
]
}
```
They are then used like so:
Configure + Build with GCC: `cmake --workflow --preset gcc-debug-arm64`
Configure + Build with Clang: `cmake --workflow --preset clang-debug-arm64`
Configure + Build with Clang (x64): `cmake --workflow --preset clang-debug-x64`
*Addendum: It should also now be possible to cross-compile from Windows to Unix-likes, and Unix-like to other Unix-like (e.g. Linux -> FreeBSD), however this is untested.*
This change was causing some issues:
> Made FMT_STRING a no-op when FMT_USE_CONSTEVAL is enabled, since the consteval format-string constructor already provides compile-time validation (#4611, #4612). Thanks @friedkeenan.
A few actions were missing from shortcuts in the Tools menu. This allows using e.g. `ALT`+(`T`>`E`>`S`) to open the Skylanders Manager, or `ALT`+(`C`>`C`>`1`) to toggle the first Wii Remote's connection.
This jumps us up two releases, both of which only introduce bug fixes. Changes potentially relevant to us are:
[3.4.6](https://github.com/libsdl-org/SDL/tree/release-3.4.6):
- Fixed Xbox controllers being unresponsive on preview release of Windows 11
- Fixed the menu button state on controllers on Apple platforms
[3.4.8](https://github.com/libsdl-org/SDL/tree/release-3.4.8) (hotfix release):
- Fixed a controller related crash on Windows, introduced in 3.4.6
I am not certain what this was used for, but the last non-formatting related change made to it was over 16 years ago.
The project targets Windows Vista, uses a Visual Studio 2010 project.
Looking at the entry point in `DSP_InterC.cpp`, the program opens a hardcoded path to a DSP rom in `C:\_\dsp_rom.bin` without any documentation on it whatsoever, and decodes something between two mystery addresses before exiting.
Previously, SDL would `find_package(libusb)` which would actually overwrite the user preference in the case where both USE_SYSTEM_LIBUSB and USE_SYSTEM_SDL were OFF. This coincidentally also allows SDL to use libusb on Windows.
Our FindLibUSB.cmake was previously entirely unused unless SDL was being built from Externals, we now rely on it again. It will use PkgConfig if applicable or fall back to looking around on the system, and more importantly it will always create an imported target.
cURL tries to find ZSTD anyways due to the lack of setting it in CACHE, and for both ZLIB and ZSTD if we had done find_package previously, cURL would still use ZLIB/ZSTD regardless of the set variable.
This also fixes the CMake build on Windows, since it would fail to find our target defined in Externals and would fall back to trying to redefine it, which produces an error.
Currently, configuring from System>Bundled doesn't work, it instead produces cryptic errors. And configuring from Bundled>System wont produce errors, but wont use the system libraries either. This change produces a clear error in both cases.
Notable changes:
- CMake
- Fixed a bug where SDL couldn't use a vendored libusb or libhidapi (see 29b3fcfb1bc834d0187a8114debdcbbf8381cd61)
- Fixed long startup times on Windows when some non-compliant input devices are present
- Controller support
- Added support for the Razer Raiju V5 Pro
- Improved Switch 2 controller support
- Improved NVIDIA SHIELD controller support
- Fixed various controllers showing up twice on macOS
- Fixed handling GameCube adapters in PC mode on Linux and macOS
If using CMake and Ninja or any CMake generator that isn't Visual Studio on Windows, the `-include` will be ignored and the implot fix will not be applied.
cpp-ipc is explicitely only available on Windows, Linux, QNX, and FreeBSD. Trying to build dolphin on any another BSD such as OpenBSD or Haiku currently leads to failure because of this.
Recently came across a strange issue where Dolphin would hard crash in most games with this error:
```sh
/usr/include/c++/15.2.1/optional:1165: constexpr const _Tp* std::optional<_Tp>::operator->() const [with _Tp = InputCommon::ImagePixelData]: Assertion 'this->_M_is_engaged()' failed.
```
The culprit turned out to be accessing `host_key_image` which is an `std::optional` thay may return `std::nullopt`. I'm not sure why this issue started occuring for me since I've had no issue with my Dynamic Input Textures in the past? But this fixes a crash if the image fails to load.
This fixes a build error when `-DENABLE_TESTS=ON` and `-DUSE_RETRO_ACHIEVEMENTS=OFF` are both set together, since AchievementManager is also behind an ifdef.
OProfile is not used at all these days, most major distributions do not ship it anymore (Debian, Fedora, and Alpine to name the few I've checked) and following a discussion on Discord, nobody is apparently using it, most devs not even being aware of it. This removes an optional dependency from Dolphin.
In certain cases, the platform can be "wayland-egl", "wayland-xcomposite", and other values for which I haven't found a full list yet. Instead of matching only "wayland", we now look for "wayland" anywhere in the `QT_QPA_PLATFORM` string in a case-insensitive manner.
Acknowledgements:
`CaseInsensitiveContains`' implementation was heavily inspired by GNU's non-standard glibc `strcasestr` function, which can be found here licensed under GPLv2 or later: https://ftp.gnu.org/gnu/libc/
Dual Core is primarily known as one of the first troubleshooting steps when emulation or NetPlay misbehave.
I believe(?) the original intent with having it on by default was likely to support users with weaker machines. However, I believe it would be a lot more reasonable for users to manually enable dual core if they really need the performance boost, rather than it is for them to have come ask us in support channel why their cleanly-installed Dolphin is not emulating their games properly.
Instead, this creates a fragile first impression where a clean install of Dolphin is already set up in a way that leads to inexplicable crashes, subtle timing bugs, and NetPlay desyncs.
Note: This changes only applies to the Desktop application, since mobile devices *do* really need the performance boost.
Joshua Vandaële