* macos: fix Vulkan/Metal renderer on macOS 26+ and bump MoltenVK
Four related changes that together let the Vulkan backend boot a game
on Apple Silicon Macs running macOS 26.x. Each is needed independently;
the combination was tested on a Mac16,6 (M4 Max) / macOS 26.4.1.
CMakeModules/DownloadExternals.cmake:
Bump bundled MoltenVK from v1.2.9 to v1.4.1. v1.2.9 does not
recognize macOS 26 surface objects and traps with an Objective-C
"unrecognized selector" inside vkGetPhysicalDeviceSurfaceCapabilitiesKHR.
src/video_core/renderer_vulkan/vk_instance.cpp:
Disable VK_EXT_tooling_info on MoltenVK. MoltenVK advertises the
extension but does not expose vkGetPhysicalDeviceToolPropertiesEXT
through its dispatcher, so the call inside CollectToolingInfo()
trips a vulkan-hpp assertion in Debug and dereferences NULL in
Release.
src/citra_qt/bootmanager.cpp:
Force-install a fresh CAMetalLayer on the NSView before handing it
to createMetalSurfaceEXT. Qt 6.11's QWindow::MetalSurface does not
always back the view with a CAMetalLayer on macOS 26, and MoltenVK
1.3+ aborts in MVKSurface::getNaturalExtent() if the layer is not
the right class. Implemented via objc_msgSend so no .mm conversion
is needed.
src/citra_meta/CMakeLists.txt:
Gate LaunchScreen.storyboard behind 'if (IOS)'. The storyboard is
iOS-only and previously broke the Xcode generator on macOS with
"iOS storyboards do not support target device type 'mac'."
* Move Metal layer creation logic into MetalUtil::CreateMetalLayer ObjC++ function
This change makes the code much more readable, as the logic is now in its native language
---------
Co-authored-by: SergeyMild <>
Co-authored-by: OpenSauce04 <opensauce04@gmail.com>
* Convert all setting keys in settings.h into hana strings
* Derive libretro setting keys from common/settings.h hana strings
* settings.h: Reduce code repetition in key definitions via macro
* Implemented mechanism to pass our C++ setting keys to Android/Kotlin
None of the Android keys have been moved over as of this commit, this is just prep work
* jni_settings_keys.cpp.in: Removed redundant code
* Migrate (almost) all Android setting string keys over to SettingKeys
Also some slight cleanup
* Updated license headers
* Fixed top custom width erroneously being used in place of top custom height
* Migrate (probably) all setting string keys to Settings::QKeys
* Migrated several previously missed string keys to generated keys
* SettingKeys.kt: Visually seperate shared and Android-exclusive keys, similar to GenerateSettingKeys.cmake
* android: sdl2_config --> android_config
Not sure why these values are named this way. Hold-over from SDL2 frontend?
* android: Generate and validate default config.ini dynamically
* Settings: Assume C-style string keys by default
Relative to the previous commit, the following names have changed:
- Settings::Keys --> Settings::HKeys
- Settings::CKeys --> Settings::Keys
* default_ini.h: Fixed formatting warning
* Comment cleanup
* android: Fixed compilation failure due to incorrect namespace
* config.cpp: Use ASSERT_MSG instead of LOG_ERROR and ASSERT(false)
Otherwise, the configuration on darwin fails for me with the following
error:
```
CMake Error at src/citra_meta/CMakeLists.txt:64 (target_link_libraries):
Target "citra_meta" links to:
Qt6::GuiPrivate
but the target was not found.
```
Signed-off-by: Marcin Serwin <marcin@serwin.dev>
Enables the use of SSE4.2 instructions on x86_64 CPUs, allowing
compilers to automatically vectorize some loops on citra_common.
A CMake toggle ENABLE_SSE42 (ON by default) has been added
to enable this behaviour.
This change breaks compatibility with CPUs that do not have
SSE4.2 instructions. All modern CPUs (from 2011 onwards) should
always have these instructions. Manual compilation will be
needed for older CPUs.
A message has been added to report if the CPU is incompatible
when starting the emulator.
Co-authored-by: OpenSauce04 <opensauce04@gmail.com>
