We are updating from 3.4.8
Changes relevant to us include:
3.4.10:
- Added controller sensor support for GameInput v3
- Fixed Ipega controllers being ignored in keyboard mode
- Added support for GameCube rumble when the adapter is in PC mode and has the latest firmware
- Fixed rumble on the new Steam Controller
- Added support for the GameSir Super Nova in Xbox 360 mode
- Added support for the PDP Afterglow Wave Wireless Controller for Switch
3.4.12:
- Added hotplug detection support when using libusb for HIDAPI controllers
- Fixed flipped Xbox 360 controller axes on macOS
It's not in the changelogs, but 3.4.10 is the revision which allowed for my Steam Controller's gyro to properly work in Dolphin
Since our bump to Qt, dxcompiler.dll and dxil.dll have been added alongside other Qt dlls as part of QtGui. Those DLLs are not needed since we use QtWidgets and not QML.
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.
Joshua Vandaële