* 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)
* libretro core
* Bringing citra libretro implementation over
* libretro: hook up vulkan renderer
* libretro: github actions
* libretro: gyro
* libretro: core options v2
* libretro: on ios turn off shader jit if unavailable
* moltenvk 1.3.0 introduces 8-bit indexes but allocates 16-bit for metal; this ends up allocating stream buffer * 2 = 132MiB. Instead, just use 16-bit indexes. (This will be necessary for standalone when bumping moltenvk version.)
* libretro core: address review feedback
* libretro: microphone support
* cmake: Add ENABLE_ROOM_STANDALONE to list of incompatible libretro flags
* libretro: proper initial geometry
* libretro: fix software renderer
* libretro: address review feedback
* .github/libretro.yml: Pin macOS runners at macOS 26
* ci: Remove explicit selection of Xcode 16.0
* .github/libretro.yml: remove unnecessary windows builder apt commands
* .github/libretro.yml: bump min macos version to 11.0
* ci: Re-enable CI jobs for all libretro cores
This is under the condition that we don't introduce build cache for these builds
---------
Co-authored-by: OpenSauce04 <opensauce04@gmail.com>
Co-authored-by: PabloMK7 <hackyglitch2@gmail.com>
* code: Remove some old msvc workarounds
* android: Upgrade to NDK 26
* Allows access to newer libc++
* common/swap: Make use of std::endian
Allows removing a bunch of defines in favor of a two liner.
* common: Remove misc.cpp
* GetLastErrorMsg has been in error.h for a while and also helps removing a depedency from a hot header like common_funcs
* common: use SetThreadDescription API for thread names
* common: Remove linear disk cache
* Has never been used?
* bit_set: Make constexpr
* ring_buffer: Use feature macro
* bit_set: Use <bit> and concepts
* gsp_gpu: Restore comment
* core: Ignore GCC warning
---------
Co-authored-by: Lioncash <mathew1800@gmail.com>
Co-authored-by: Liam <byteslice@airmail.cc>
* build: Rework CI and move all bundling into new build target.
* ci: Use "mingw" in msys2 release names for compatibility.
* ci: Use "osx" in macOS release names for compatibility.
* ci: Disable macOS upload.
Will be moved to a separate PR for canary merge.
* tests: add Sanity test for SplitFilename83
fix test
fix test
* disable `C4715:not all control paths return a value` for nihstro includes
nihstro: no warn
* Chore: Enable warnings as errors on msvc + fix warnings
fixes
some more warnings
clang-format
* more fixes
* Externals: Add target_compile_options `/W0` nihstro-headers and ...
Revert "disable `C4715:not all control paths return a value` for nihstro includes"
This reverts commit 606d79b55d3044b744fb835025b8eb0f4ea5b757.
* src\citra\config.cpp: ReadSetting: simplify type casting
* settings.cpp: Get*Name: remove superflous logs
This significantly reduces unnecessary disk writes and space usage
when building Citra.
libcore.a is now only ~1MB rather than several hundred megabytes.
Previously we were building with MBCS, which is pretty undesirable. We
want the application to be Unicode-aware in general.
Currently, we make the command line variant of yuzu use ANSI variants of
the non-standard getopt functions that we link in for Windows, given we
only have an ANSI option-set.
We should really replace getopt with a library that we make all build
types of yuzu link in, but this will have to do for the time being.
By default, MSVC doesn't use standards-compliant volatile semantics.
This makes it behave in a standards-compliant manner, making
expectations more uniform across compilers.
The C++ standard allows constexpr variables declared with the extern
keyword to have external linkage. Previously MSVC wasn't abiding by
this. This just makes the compiler more standards compliant during
builds.
Given we currently don't make use of anything that would break by this,
this is safe to enable.
* CMakeLists: Move compilation flags into the src directory
We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to
append flags to the targets, since this adds the compilation flags to
everything, including our externals, which can result in weird issues
and makes the build hierarchy fragile.
Instead, we want to just apply these compilation flags to our targets,
and let those managing external libraries to properly specify their
compilation flags.
This also results in us not getting as many warnings, as we don't raise
the warning level on every external target.
* CMakeLists: Move off of modifying CMAKE_*-related flags
Modifying CMAKE_* related flags directly applies those changes to every
single CMake target. This includes even the targets we have in the
externals directory.
So, if we ever increased our warning levels, or enabled particular ones,
or enabled any other compilation setting, then this would apply to
externals as well, which is often not desirable.
This makes our compilation flag setup less error prone by only applying
our settings to our targets and leaving the externals alone entirely.
This also means we don't end up clobbering any provided flags on the
command line either, allowing users to specifically use the flags they
want.
