This minor change in src\video_core\renderer_vulkan\pipeline_helper.h allows renderdoc capture on mhr sunbreak.
Maybe it sanitizes some crashes on old vulkan GPUs.
Device log (nvidia kepler gpu vulkan 1.1.117):
[ 17.605262] Render.Vulkan <Info> video_core\vulkan_common\vulkan_device.cpp:1041:GetSuitability: Device doesn't support feature nullDescriptor
VUID-VkWriteDescriptorSet-descriptorType-02997
For sampled/combined/storage image descriptors, Khronos says imageView must be valid or VK_NULL_HANDLE
(https://docs.vulkan.org/refpages/latest/refpages/source/VkPhysicalDeviceRobustness2FeaturesKHR.html)
but then it says: if nullDescriptor is not enabled, imageView must not be VK_NULL_HANDLE.
(https://docs.vulkan.org/spec/latest/chapters/descriptorsets.html)
nullDescriptor is exactly the feature that allows descriptors to be written with null handles.
The fix relies on conditionally replacing the null sampled view with Eden’s dummy null-image-view object (ImageView constructor checks HasNullDescriptor which checks features.robustness2.nullDescriptor. cheap checks, and only for null handles, so no notable cost).
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4056
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
FIXES A REGRESSION FROM 4012.
TryFindSize's Mesa fallback matched the unconditional @PT EXIT (0xE30000000007000F) that nv50_ir emits at program end.
That exact word is also emitted by NVN mid-program for unconditional early-outs, so on retail titles (e.g. Super Mario 3D World) the scan truncated at the first early EXIT and dropped the rest of the shader, making textures vanish.
Mesa's terminal EXIT and NVN's mid-program EXIT are bit-identical, so no mask can separate them. Gate the heuristic on !is_proprietary_driver:
NVN binaries (bindless cbuf slot 2) keep self-branch-only sizing, while nouveau/Mesa homebrew (single terminal EXIT, no self-branch trailer) still uses the EXIT terminator. nv50_ir emits exactly one EXIT (early returns lower to BRA-to-exit, discard to DISCARD), so a single terminal match is correct for that path.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4151
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
#3908 changed process_creation.*, CreateProcess/CreateApplicationProcess, to return std::optional<Process> instead of std::unique_ptr<Process>, so the AM sites now transfer a Process by value via make_unique<Service::Process>(*std::move(opt)).
The consequence: Process owns a refcounted KProcess* but its user-declared dtor suppressed the implicit move ctor, so that "move" silently shallow-copied and the temporary's dtor Close()/RemoveProcess()'d the shared handle -> use-after-free.
It's seems to be user end based, so whether it crashes may depend on machine, compiler, allocator reuse, refcount slack, and the AM event-observer thread race, idk. It reliably crashed my MSVC build at launching games (cstack: ProcessHolder -> MultiWait -> KSynchronizationObject::Wait -> null) multiple times.
Fix: give Process a move ctor that steals the handle (nulling the source so the moved-from dtor is a no-op) and delete copy/move-assign, making the optional<->unique_ptr transfer safe.
Bonus: explicited delete for the 3 kinds of assignment: copy ctor (the one used in eden), copy assign and move assign (currently unused) to force compile error if they ever come to use.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4137
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
EDS3 states were dynamic just because the driver supports them. But in EDS0-EDS2, we does not actually emit the EDS3 dynamic commands for them. So the pipeline builder skipped baking some fixed graphics state into the Vulkan pipeline, but the runtime also did not set that state dynamically. That leaves wrong Vulkan state during rendering causing rendering glitches in XC2.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4117
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This add winding application function. Test this by opening qlaunch -> top left Profile -> edit profile picture -> go back (do not save if you are on fw21+, it corrupts the image)
And reverts in #3908 added `optional<Process>` to `unique_ptr<Process>`
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4134
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Added an option to control the GPU buffer readback, as it causes issues if the hardware cannot keep up with the additional workload.
Some games require this to render certain effects properly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4126
Inline index draws arrive as a batch but were processed one word at a time, so each index ran through the full per-method path and got appended a byte at a time.
Handle the whole batch in one pass instead, updating state once and appending all the indices together. Replay shadow control still goes word by word since it has to reload each one.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4083
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
5af7771f83-Bugfix: Made gpu_log_level global-only (was per-game switchable). Fixed Android non-determinism where a per-game profile silently overrode the global to Off and trapped GPULogger::Initialize() in a dead state, making shader dumps fail invisibly. Android per-game UI now hides the whole GPU logging block; Qt UI is untouched (global-only anyway).
bf4aabe8ab-Refactor/Cleanup: Removed gpu_logging_enabled master toggle as redundant with gpu_log_level == Off. Introduced GPU::Logging::IsActive() helper, replaced 14 call sites across vk_*.cpp. Refactored LogShaderCompilation() to be text-only and extracted SPIR-V dumping into a standalone GPU::Logging::DumpSpirvShader() free function. No singleton dependency, gated only by gpu_log_shader_dumps. Now gpu_log_level and gpu_log_shader_dumps are fully orthogonal. Cleaned up Android (BooleanSetting, SettingsItem, presenter, 7 locale string files).
865a1c5027-Refactor: Renamed dump_shaders → dump_guest_shaders to disambiguate from gpu_log_shader_dumps. Updated Qt label to "Dump Guest (Maxwell) Shaders" and rewrote the tooltip to mention .ash, the DumpDir/shaders/ location, and nvdisasm.
7cab456fdf-Feature: Added Qt UI control for GPU log level in the Logging session. Added gpu_log_shader_dumps checkbox to the Graphics column right below dump_guest_shaders.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4018
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
GetMacroAddress only reads a couple of indices per macro, but ProcessMacro was
then building a full std::vector GPUVAddr> with one push_back per parameter word
every submission. macro_segments already holds base, count per chunk, so
GetMacroAddress can just walk it instead, drops the per-word loop, a
.clear(), and a vector member.
Also makes it so it returns on the first match in the macro dispatch instead of running every
std::get_if check.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4067
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Adds a basic carousel view, or essentially a horizontal list a la Android/Qt Quick.
Lacks a lot of niceties like autoscroll, smooth shifts, etc. Will work on those later
Also fixed a bug introduced recently that capped game icon size to 8 at the low end, breaking the None option
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4112
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Prevent the CPU from getting too far ahead of the GPU by limiting pending flushes.
This fixes graphical issues in games that rely on better CPU and GPU synchronization in the Scheduler, such as the flickering bug inside shrines in The Legend of Zelda: Tears of the Kingdom.
This is enabled when the GPU is in Accurate mode.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4085
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
- Remove unnecessary icon update code (the UI reloads this stuff anyways); test on Windows please
- Cleaned up a bunch of duplicated/unused code within the game list
- Fix the game list constantly reloading on macOS
* When you reconstruct the entire directory list on the watcher the directoryChanged signal fires on macOS--seems like a behavioral change that occurred somewhere in the 6.8 release cycle--and it would enter an infinite loop very quickly
* To fix this, only the differences between the current and old watch list are accounted for on both ends.
* Since this bug is now fixed, macOS uses Qt 6.11.1 now. Should theoretically improve our situation.
- Fix the external content watcher crashing; the worker would attempt to read files that didn't exist without any bounds since its cache was still pointing to that file.
This supersedes and replaces #4099.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4106
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
So the game list watcher could rebuild the content providers
(CreateFactories) while the populate worker was still scanning them, and
the worker would walk a torn-down RegisteredCache and segfault in
OpenFileOrDirectoryConcat. Fixed by stopping and joining the worker
before rebuilding.
On macOS the watcher also re-armed itself every populate. Re-adding the
same paths makes QFileSystemWatcher re-emit directoryChanged (the
FSEvent comes in async, so the blockSignals guard misses it), so it just
kept refreshing and the list flashed forever. Now it only re-arms when
the watched dirs actually changed.
Also null-guarded OpenFileOrDirectoryConcat so a torn-down cache cant
null-deref there.
Related: https://github.com/eden-emulator/Issue-Reports/issues/336
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4099
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
makes it so the shader cache goes properly in `XDG_CACHE_HOME`.
SOME people have it set to point to `/tmp` AND as a ramdisk, if they can do that they probably would want their shader caches to be there as well and wouldnt mind the extra hit from invalidations on reboot.
afterall, its a cache, not some holy data that needs to be kept at all costs.
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4093
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
The GL shader profile hardcoded max_user_clip_distances to 8. Query the
device limit like the Vulkan path already does (it reads
maxClipDistances), so we use what the host actually reports.
Clamp to Maxwell's NumClipDistances (8) since the guest never produces
more than that and the SPIR-V output array is sized for at most 8. So a
host reporting fewer than 8 is respected, and one reporting more can't
overrun anything.
Fixes#3910https://git.eden-emu.dev/eden-emu/eden/issues/3910
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4095
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
two main issues:
shader_environment.cpp
Support Mesa nv50_ir-compiled homebrew fragment shaders
Mesa nv50_ir (used by NZP-Switch via libdrm_nouveau) emits Maxwell SASS that differs from NVN in two ways our shader pipeline didn't account for, causing "infinite" loops during shader scanning.
How? TryFindSize() previously detected end-of-shader only via NVN's "BRA $-1" self-branch trailer (SELF_BRANCH_A/B). Mesa-compiled shaders end with an unconditional @PT EXIT and emit no trailer, so scanning ran past the shader and looped to MAXIMUM_SIZE.
Fix: Added a secondary match against @PT EXIT T (opcode 0xE30, predicate PT, flow T) as a fallback terminator. The mask is estrictive enough to reject predicated EXITs, conditional-flow EXITs, and sched control words, so well-formed NVN shaders see no ehavior change (their single @PT EXIT immediately precedes BRA $-1, and both detections return the same size).
load_store_attribute.cpp + attribute.h
IPA's is_perspective check only applied the ×position_w correction for IR::IsGeneric() attributes, and used a per-component SPH lookup. Two failure modes followed:
1. Mesa fragment shaders read varyings via legacy attribute slots
(ColorFrontDiffuse, FixedFncTexture, FogCoordinate) which are
remapped to generic varyings later by ConvertLegacyToGeneric. At
IPA-translation time they're still legacy, so IsGeneric() was
false and the inject was skipped — but the resulting GLSL/SPIR-V
varying was Smooth (perspective-correct), and the SASS still
issued its manual perspective dance via MUFU.RCP(ATTR_W)+FMUL,
compounding an extra ×clip_w factor. NZP fog (eye_z distance
varying) ended up as eye_z⁴×density² instead of eye_z²×density²,
saturating fog to white everywhere.
2. Even for legacy attrs that should inject, Mesa stores them in two formats selected by the IPA's interpolation_mode field:
Pass/Multiply/Constant → attr/w (perspective); inject ×position_w
Sc (ScreenLinear) → raw attr; do NOT inject
Unconditionally injecting for Sc dims vertex colors by 1/clip_w because there's no SASS multiplier to round-trip it back.
Fix: extend the IPA correction path to also fire on IsLegacyAttribute(), gated on interpolation_mode != Sc. While here, the generic-path check is widened from per-component to vector-level (first non-Unused PixelImap, with all-Unused fallthrough treated as Perspective) so it matches the GLSL interpolation qualifier picked by CollectInterpolationInfo — this fixes the same all-zeroed-imap case Mesa exposes for explicit generics. IsLegacyAttribute moved from translate_program.cpp's anonymous namespace into attribute.h next to IsGeneric so IPA can reach it.
Tested on NaziZombies:Portable (Switch homebrew): fog now matches real
hardware, vertex-colored geometry (hand, gun, decals) renders correctly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4012
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Homebrew (.NRO) program args support
Adds a 'program_args' setting and delivers it to NRO homebrews via libnx's homebrew ABI. NROs previously had no way to receive CLI flags (e.g. NZ:P's -noglsl).
Setting: program_args, Category::System, startup-only.
Surfaced in Qt + Android Debug sections.
NRO loader: builds a 4-entry 'ConfigEntry' table + argv at the data segment tail; prepends 'homebrew ' so user args land at argv[1]; scans for 'svc #7' to use as LR. Drops the stale NSO-style argdata append.
KProcess: stores loader-provided guest addresses; 'Run' switches to the homebrew entry (x0=config_ptr, x1=-1, lr=svc7) and patches the real MainThreadHandle into the ConfigEntry slot. Legacy NSO path unchanged.
Tested on NZP — args reach 'argv' correctly.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4013
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
OpenSaveDataFileSystem was missing a few SaveDataSpaceId mappings, so it would hit ASSERT(false). This broke games that open cache storage, with TOTK being the obvious one, because save enumeration could assert before the game even finished loading.
Fixed this by mapping Temporary to user nand, and ProperSystem/SafeMode to system nand. These only get used for the free-space check here, so they just need to point somewhere sane.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/368
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4069
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Adds an NSIS Windows installer file. Includes:
- Installation to `user\AppData\Local\Eden` (user install; does not require administrator and makes the integrated updater work and same as e.g. yuzu, Citra, Azahar)
- Shortcuts for Start Menu and optionally to Desktop
- File association with `.nsp`, `.xci`, `.nro` and `.kip`
- Throughout uninstallation and registry cleanup
And finally, needs to be implemented into the GitHub CI workflow, will submit a PR there later uwu
Co-authored-by: RedBlackAka <140876408+RedBlackAka@users.noreply.github.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4008
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
GetIndexFromAruid returns AruidIndexMax as the “not found” value, but both
GetControllerFromNpadIdType overloads were using that value to index
controller_data without checking it first.
when a game routes through DisconnectNpad before its applet resource is
registered, we can end up indexing past the end of controller_data. That seems
to be what was crashing some games on launch, especially on macOS and Android,
where the out-of-bounds read is less likely to just slide by unnoticed.
So yeah, AruidIndexMax is a sentinel, not a real controller_data index, so we
should not treat it like one.
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/438
Fixes: https://github.com/eden-emulator/Issue-Reports/issues/439
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4064
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This fixes an Android game library scan crash when reading XCI title metadata with empty or incomplete NACP language entries.
Previously, NACP::GetLanguageEntry() could fall back to:
language_entries.at(static_cast<u8>(Language::AmericanEnglish))
When language_entries was empty, this threw std::out_of_range and aborted the Android scan thread.
The new fallback preserves the existing lookup order:
1. preferred language entry with non-empty application name
2. any entry with non-empty application name
3. first available entry
4. static empty LanguageEntry if no entries exist
Tested locally with a Mainline RelWithDebInfo APK on Odin3 Android 15 using a large external TF-card ROM directory. The previous build crashed during fresh ROM scan; the patched build completes scanning normally.
Related my issue:
https://github.com/eden-emulator/Issue-Reports/issues/500
Co-authored-by: bdm110 <bdm110@prontmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4062
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
most stdlibc++ already provide this functionality out of the box, very consistently and well implemented (usually)
my main irk is that the llvm itanium demangle is totally unescesary when there is a perfectly stable, tested and well documented equivalent functionality in the standard stdc++ provided in most UNIX oses
its mostly to reduce binary size by a very thin margin, but he stdc++ is more than capable of doing he same behaviour we use a dpeendency for
for mingw or such howeger,, demangling becomies trickier so we have to exclude windows entirely because well windows likes to do things differently dont they
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3894
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This fix a bug in which eden crashes when renderdoc is attached to vulkan.
that kept me away from renderdoc for around a year now.
the bug:
in video_core\renderer_vulkan\vk_staging_buffer_pool.cpp
in GetStreamBufferSize(...)
if device.HasDebuggingToolAttached()
but heap is empty/unavailable <-- Case in my old nvidia kepler gpu
the original method returns size 0, right?
the change honors same original behavior, while covers my case properly, returning MAX_STREAM_BUFFER_SIZE.
addl some log tip and some minimal doc. fully safe. let it rip.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4052
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Something weird is happening with the CI that causes frequent build errors. For reasons I am not entirely certain of, Ninja fails to properly spawn a POSIX shell instance during the Make phase.
More investigation is in order, but for now fix it with the grand power of shelling out to CMake script
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4047
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Closes#3480
moves the game list model/worker/private stuff to qt_common for later
use in QML
- `qt_common/game_list/model.{cpp,h}` is the model
- `yuzu/game/game_{grid,tree}.*` are the views
- `yuzu/game/game_list.cpp` is the presenter
This was done very lazily in a manner that "works" while largely
maintaining existing structure as much as possible. Most of it is
copy-paste, with some bonus reworks/cleanups thrown in.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4042
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
e.g. Serfrost's Defogger will now be named "Serfrosts Defogger" by
default, instead of "serfrosts_base_defogger_v2-4"
Note that for atmosphere mods it still uses the zip folder name, since otherwise their default name will just be the game's Title ID.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4043
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
If YUZU_USE_BUNDLED_OPENSSL is off and OpenSSL is *not* installed to the
system, pulls in OpenSSL and Jimmy Park's CMake wrapper, then configures + builds from source.
Some patches were made on top of OpenSSL and openssl-cmake:
- USE_CCACHE is respected from UseCcache.cmake
- CXX/CFLAGS are passed from CMake to the configure script, which sends
those to the compiler
- Uses a bundled cert.h akin to the bundled OpenSSL build
Closes#3614
~~Before merge: remove verbose stuff~~ actually useful so nvm
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4032
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
fixes an yxzx era bug where eden assumed NVN-style packed SSBO descriptors (u64 gpu_addr followed by size) only happen in cbuf_index == 0.
Mega Man Star Force Collection proves that assumption is false. It has an unbiased/global-memory SSBO descriptor in cbuf_index == 3, offsets 0x100/0x300, but the descriptor still appears to be { address, size }.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4041
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
This PR aims to fix some regressions found in the latest release 0.2.0, which were a bunch of constant crashes/ random on certain Android devices with issues with the PiP configuration, addressing some problems founds for AMD after the maintenance of 2nd Global Vulkan Maintenance.
-> Fixes Final Fantasy Tactics on AMD (no longer requires of generic bits to work "all commands bit")
-> Fixes some performance regressions on android due to the Tomodachi fix applied globally as common behavior (#3898, #3900)
-> Fixes blittering of screen found on ARM Windows devices and QCOM stock drivers (Android and ARM Windows) related to Mario Kart 8 Deluxe strange blittering in races, caused by a strange race condition with the ResetQueryPool and mostly the workaround for presync
-> Fixes issues on Luigi's Mansion 3 issue where the pause screen became black on AMD due to the early reset of queries.
-> Fixes crashes on Mario Party Jamboree for AMD/ Nvidia.
-> Keeps previous fixes related to crashes on AMD with other games such as Astral Chain, Fire Emblem Three Houses and Xenoblade 3 based on the lack of access to vertex fragment replaced with generic flags.
-> Fixes TOTK RADV skybox lighting.
--------
Credits:
@melod-y
@Gidoly
@MaranBr
@AlexWolff
@Lizzie
And all the people who contributed into the reporting issues/ helping with the bisect.
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3953
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
This fixed issues in Mario Kart 8 multiplayer where the native controller applet would pop up, then once A was pressed and it exited, it would freeze the game but music would continue playing.
The issue was that UpdateRequestedFocusState() updates the focus state but never sets m_has_focus_state_changed for applications. Since ShouldSignalSystemEvent() checks that flag for applications, they never receive FocusStateChanged messages when LLE library applets exit. The game keeps running (hence the music) but is stuck waiting for a focus notification that never arrives. HLE applets aren't affected because their dummy process has is_process_running=false, so the game is never considered obscured in the first place.
Credits: [davidcollini](https://github.com/davidcollini)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4027
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
when shutting down the emulator will silence any remaining audio from the output buffer
however this is for some reason stored in an array instead of being a simple memset
additionally, said array can be small enough (`frame_size_bytes > silence.size()`) to cause a funky noise to play at the end
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3969
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
This implements MWAITX and WAITPKG extensions (umonitor, mwait) for CPUs that support them.
Reduces wait times and bypasses the timing stuff from the OS that is slow (windows notably). generally it should answer within 0.2 to 0.5 microsecs (since most requests wait for that long).
Also does a general rework of static ctors and stuff
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
before vs. after
Mario Brothership kept remaking vectors of sizes 256 AND 4095 (TIC) and 1215 AND 524287 (TSC) every single frame, which resulted in a noticeable overhead
the main cause was because of using `resize(n, c)` instead of `resize(n)` (also to aggressively resize for more room beforehand), the copy overload of resize does a copy of... well.. the value over the entire vector, additionally __append() keeps getting called because the capacity goes bonkers and all over the place


Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3874
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Matches the build ID and compiler now.
Note that this could still use some work on the Windows side of things.
Ideally, it would just replace the executables in place; however, I
think using the setup files will be better.
Most of my concerns w.r.t this issue is that users will want to install
multiple in the same place; however, I think it's fair to just not
support the older versions at all for now. If users really want to do
that, they can use the portable versions and cry about it.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4019
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
u8 may have been 0xff, (aka. 255), but bitset was only 255 elements, so doing bitset[255] is technically OOB
additionally the max size estimate for index formats was not correct, there can be up to 256 elements with a u8 format index, not just 255
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4006
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
in short:
unrelated to the toggle, we found a missing piece that improved antiflicker and shader issues in some games, and we integrated it to balanced/accurate.
now testers confirmed side effects in some other games, so we reverted the integration.
the toggle itself is innocent. and the missing piece was kept for the toggle.
now, when the toggle is off, things are as they were before it.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4010
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Amaterasu from Discord asked about why nvnWindowGetNumActiveTextures returns 0 - after researching the console output it was asking for `DefaultDataSpace` (enum val 12) after some tests with the mod and debugging the console, this is my one-liner solution.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3956
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
tldr: we (me and maran) found the missing piece to make delay_fence and should_flush coop and cover all remaining flicker issues tested so far.
the lil change is in src/video_core/fence_manager.h
the rest is toggle stuff.
END
(credits rolls up)
post credits scene for the toggle drama:
i've been forced to use custom builds for around 1 year now, coz gpu mode above fast was pulling performance down yet not covering flicker entirely in most games tested. and we know that it's a mess to rely on gpu mode as it brings along a bunch of undesired stuff.
i need this toggle. and i've seem far less relevant before, so hey, gimme this one so i can call it mine :3
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4004
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
This PR reloads Android configuration when starting a game, so Eden uses the latest config.ini state for the emulation session.
On some Android launchers, Eden can already be running in the background before a game is launched. In that case, config.ini has already been read, so configuration changes made outside of Eden's settings flow while the process is alive are not picked up by the next emulation session.
This improves launch/config behavior for external launcher workflows.
Co-authored-by: FL-gs <efge.crea@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3965
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
traditionally, when doing jthread:
```
jthread() calls function parameter operator()() with args
function operator()() calls the code within
code within is, say { ThreadMain(); }
3 calls because why not
```
now this just makes it be 2 calls, mainly benefits non-LTO builds
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3970
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Removes Eden's own feature detection for SSE, SSE2, FMA4 and AVX_VNNI, in order to clean up code and make the function slightly lighter. They are all unused and I have specific reasons for their removal:
- SSE/SSE2 are always true for x64
- FMA4 is a deprecated AMD exclusive extension, replaced by the regular FMA and was logged here as "FMA" for no reason
- AVX_VNNI simply does not seem applicable for Eden (but can still be checked for through Xbyak's feature detection if necessary)
Co-authored-by: RedBlackAka <140876408+RedBlackAka@users.noreply.github.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3979
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
hbloader is required to launch a bunch of shit (particularly hbmenu)
however due to some restrictive metadata validation, it doesn't get recognized as an NSP file
programs like hbmenu require hbloader (since it feeds them data like ConfigEntries and whatnot), launching hbmenu as-is standalone will result in a launchInit() error
adds an option to launch hbmenu via command line
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3981
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
Since the launch of the steam controller I think it's only best to push towards updating to SDL3 allowing for a wider range of controller support
I went ahead and started on getting it working. Everything here should be functional, I've personally tested it all on Arch Linux. Still untested on windows, so looking for feedback on that
Any feedback and help would be appreciated!
Main changes:
- Bump everything to SDL3
- Handle SDL3 audio and input
- Add steam controller support, including HD Rumble
- Improved battery reporting via the status icon by using real % rather than state alone
Co-authored-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3952
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
this makes it so VK and OGL backends map the NVIDIA's ETC2 into VK_FORMAT_ETC-whatever and GL_ETC-whatever remaps, instead of using the default fallback for AR8G8B8. in short, just make the ETC2 textures be submitted as ETC2 instead of being submit as A8R8G8B8.
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3237
Reviewed-by: Ghost <>
Reviewed-by: crueter <crueter@eden-emu.dev>
the nominal std::unordered_map<> isn't enough to warrant it's continued usage in xbyak internal structures, thus using ankerl should greatly remove a lot of indirection/stdc++ specific overhead from the usually poorly performant std::unordered_map
Both dynarmic and macroHLE should benefit greatly from a less-stupid unordered_dense
This should speedup both CPU and shader compilation latency (NOT BY A GREAT MARGIN) just enough to make loading zones in ToTK less horrific
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3716
Reviewed-by: crueter <crueter@eden-emu.dev>
so basically each construction of HLEContext and whatever would result in a heap allocation (atleast 1)
so what if instead of that we did a memset() at ctor time and we avoided heap allocations altogether?
reminder that std::vector<> CAN do small object optimisation but it's not guaranteed
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3605
Reviewed-by: crueter <crueter@eden-emu.dev>
inputs shouldnt be that critical to require a full mutex of them
this relies on CPU guaranteeing u32/u16/u8 atomic load/stores for EmulatedController fields, which works on x86_64 but may not have the same behaviour on other architectures - thats why i wrap them in `std::atomic<>`
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3866
Reviewed-by: crueter <crueter@eden-emu.dev>
sounds like word salad but let me say:
- std::map<> created a static ctor for EVERY SINGLE ZONEINFO
- fuck that, instead lets just use a raw array and construct things statically
- works the same except with less baggage carried around (+ less heap allocations!!!)
this should help reduce codesize due to the aforementioned global ctor/dtor
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3919
Reviewed-by: crueter <crueter@eden-emu.dev>
see https://github.com/herumi/xbyak/issues/255
> Proof: https://godbolt.org/z/9vseq4Ynj
> Xbyak currently implements it as:
> ```c++
> void umonitor(const Reg& r) {
> int idx = r.getIdx();
> if (idx > 7) XBYAK_THROW(ERR_BAD_PARAMETER) //umonitor DOES accept r8,r9,r10,etc this is NOT correct
> int bit = r.getBit();
> if (BIT != bit) {
> if ((BIT == 32 && bit == 16) || (BIT == 64 && bit == 32)) {
> db(0x67);
> } else {
> XBYAK_THROW(ERR_BAD_SIZE_OF_REGISTER)
> }
> }
> db(0xF3); db(0x0F); db(0xAE); setModRM(3, 6, idx);
> }
> ```
> My program was throwing Xbyak::Exception and I tracked it down to this particular umonitor
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3954
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
instead of throwing, use std::error_code and such
due to reasons unberknownst to me, the UID of the /tmp/eden directory was set for another user, this inevitably caused a crash due to wrong permissions (which is a very user unfriendly thing to do generally)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3912
Reviewed-by: crueter <crueter@eden-emu.dev>
Makes them show up in the menu & also let's them load from SDMC
Note: the android edit is totally untested and I've no clue of Kotlin but I don't see a reason why it shouldn't work
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3914
Reviewed-by: crueter <crueter@eden-emu.dev>
Changes:
- Defaults: Set Async GPU and Async Vulkan Presentation to OFF. Stability wasn't worth the trade-off.
- Threading: Lowered default pipeline workers from 7 to 4 to reduce heat and CPU contention.
- Settings: Added a slider for manual pipeline worker count so users can test what works best for their SoC.
- QCOM: Removed SPIRV bans; improves load times and thermals in heavy titles like Jump Force.
- UI: Cleaned up settings descriptions to be less ambiguous.
------------------------
Some games fixed:
-> Trinity Fusion: No longer crashes with Turnip, no longer shows the black dot in the middle of the screen on both QCOM and Turnip drivers.
-> Naruto X Boruto - Ultimate Ninja Storm Connections: Game no longer requires a fixed version of turnip to work (previously requiring Turnip driver from MESA 24.3/ @MrPurple666 EoL v2 driver)
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3886
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Testing: Luigi Mansion 3 artifact lines also happen on android.
Toggle existed on every platform but android. It works on Android and also removes the artifact lines that also happen on intel and amd gpus.
A testing PR until #3665
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3851
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
issues:
- std::function<> is used, which is famously bad
- storage of tehse in tables makes big fucking tables for no good reason
- lets just store a normal pointer and stuff! :)
this pr attempts to address that
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3920
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
theoretically, it's better because distributes load of logging across various threads
this should work because 99% of I/O solutions are blocking by default
EXCEPT, maybe android differs? please check logcat didn't get affected (again) by me underestimating android ~~stupidity~~ brillaince
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3928
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
- service manager may add a service while someone else is finding it, so properly lock
- nvhost doesn't properly account for the fact that iterators GET FUCKING INVALIDATED
- use proper exit routine for mapping locked that failed (try/catch hell)
the last two were introduced by #3858, but the first one has been present since ???
either way, remember that ankerl map has invalidated iterators upon erase/insert, so i accounted for that and SMG1 (and probably smg2) boot fine now
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3927
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
The standard build was downloading the optimized APK and vice versa due to GENSHIN_SPOOF being incorrectly defined in the mainline flavor. This should resolve the issue.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3923
Reviewed-by: crueter <crueter@eden-emu.dev>
this fixes dynamic texture descriptors that are not laid out as simple 8-byte entries
tested on steam deck/amd
notes
- DynamicDescriptorSizeShift called twice because i moved it away from the struct but doing it this way keeps the patch just in this single file than adding a new derived field in the shared struct (i also think its just a cheap recomputation anyways)
- removed cbuf scanning because i figured out how to do a bounds check statically
credits:
- Mythrax <mythrax@mytrax-rs.org> (identified the 1024 descriptor cap fix in #3897)
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3898
Reviewed-by: crueter <crueter@eden-emu.dev>
[macos] dynarmic: Implement VectorMin/Max{S,U}64 emitters (Apple Silicon fix)
Implements the missing A64 backend emitters for VectorMinS64, VectorMinU64, VectorMaxS64, and VectorMaxU64.
These IR opcodes are generated by the optimizer but lack direct hardware instruction support for 64-bit elements in the base NEON set (e.g., UMIN.2D does not exist). They are implemented using a compare (CMGT/CMHI) followed by a bitwise select (BSL). This correctly selects between the two source registers, whereas using BIT would incorrectly zero out elements.
This implementation is guarded by #ifdef __APPLE__ to ensure no impact on other platforms.
Unit tests could not be added to a64.cpp because UMIN.2D is not a valid A64 instruction, causing the assembler (Oaknut) to reject it. The fix was verified by running Team Sonic Racing, which previously crashed on this synthetic opcode.
Fixes crash in Team Sonic Racing on macOS.
Co-authored-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3421
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Checks latest release and opens a dialog containing the changelog, and
allow the user to select a specific build to download. After
downloading, it prompts the user to open it.
On Windows, this just opens up the zip in File Explorer. In the future setup files will be available. On macOS this opens up the DMG in Finder so the user can drag it to the Applications folder. Android retains the auto-update functionality from before, but updated to the new scheme. Body/View on Forgejo are not implemented, that should be in a future PR.
Additionally, moved some common httplib incantations to `Common::Net`. This will serve as the common network accessor and JSON parser from here on out.
TODO:
- [x] android :(
- [x] Search for builds based on keywords, with weights towards certain builds (e.g. macOS will search for dmg then tar.gz, windows msvc then mingw/exe then zip, etc.)
- [x] remove linux leftovers
- [x] don't allow asset selection on platforms w/o assets
- [x] nightly changelog should be in the real
FUTURE IMPLEMENTATION:
- [ ] Body/View on Forgejo for Android
- [ ] Setup files for Windows (Eden/nightly are separate) -- maybe portable/setup selector?
- [ ] Something else I'm forgetting
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3845
usual indirection removal
helps very slightly to codegen
the idea is basically to reduce the amount of pointer deference overall in the code, and use idiomatic std::variant<>-isms to not rely on vtables/unique_ptr overhead
this should allow the compiler to emit better code
of course it's a tiny optimisation and only CPU side, but allows us to reduce indirection which is almost always a good thing
"but youre passing more parameters to the function!!!" its literally memoized into a register my friend
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3758
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
there is no need to call mmap() over the mapped region as the OS will automatically map it via lazy paging
basically the mmap() and virtualAlloc on a region already allocated is a no-op (FOR THIS SPECIFIC USECASE)
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3857
Reviewed-by: crueter <crueter@eden-emu.dev>
VirtualBuffer<> would be recreated each time due to the `operator=()` from the unique_ptr<> when initializing a new process, this change makes it so said thing doesn't happen (instead it resizes the existing buffer)
this means that consecutive launches of the same process that happen to have the same process page table (or reuse it) will no longer incur a ctor/dtor path for VirtualBuffer and instead just resize the existing one
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3891
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Does NOT fix root issue with shared_memory of NPad yet, that is something probably separate
I'd like to suspect it's because every NPad by default it's expected to have shared memory, even when not explicitly initialized, but seems unlikely
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3860
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
lots of AGILEism in spirv-opt
theres BETTER alternatives like https://github.com/renderbag/re-spirv (im not gonna bother for now, it probably has shitty build system)
it sucks
the IR already resolves most of the shader code to just constant load/stores
Spirv-opt passes do not seem to make such a big difference
only introduce extra latency
like for example cbuf pass in IR already removes a lot of code, that spirv_opt would otherwise miss due to the fact it doesn't have cbuf information
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Co-authored-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3877
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
Related: [RFC3870](https://git.eden-emu.dev/eden-emu/eden/issues/3870)
Nightly and stable releases are now served through
`nightly.eden-emu.dev` and `stable.eden-emu.dev`, respectively. These
are stored using Backblaze, and served and cached through the Cloudflare
CDN. Ideally this will reduce costs, though I'll have to wait for my
first invoice to be certain.
These will serve as the new download locations going forward. Since we
have full control over this API, we can make any adjustments we want as
needed. For now, all it does is provide `tag_name`, `name`, and `body`,
the latter of which will be used for the upcoming updater PR.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3879
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
This pr is a sequel to the one merged some days ago (#3839); which aims to improve stability, graphical accuracy and better Vulkan implementation and coherency among all platforms, contains the next changes:
-> Removal of VK_EXT_unified_image_layouts: The removal of this ext was for cleaning purposes since the only part of this extension implemented was the activator; meanwhile a proper structure of use for this extension was not implemented, currently it's not viable to keep following an idea of a proper implementation due to complexity of this feature and the state of buffer cache and texture cache, which it's task that we must do near in the future, when this happens a better oportunity will arise to properly set layouts along a proper implementation of VK_EXT_descriptors_indexing, practically this feature was dead code.
-> Adjustment of VK_EXT_custom_border_color: The implementation of this feature was handled poorly and worsened during the first tries of making ExtendedDynamicState stable, by gating it's use to the slider of EDS (dyna_state) if the counter was at least in 1, even tho this entered in a bug with the RemoveUnsuitableExtension, when is not a requirement for enabling in Vulkan's documentation and was my mistake, some time later in ExtendedDynamicState refactor (#3074) I tried to make the implementation more robust in comparison the Yuzu's implementation which had bans on vendor drivers, the new handling was requesting if extension was available and what kind of support feature it had, enabling what it was available and wiring an adequate path for said available feature; which leads us to today's change, after reading carefully how certain paths weren't triggered or caused mostly issues on how extension should work I did the next changes:
- I removed the forced disabling with ExtendedDynamicState setting
- Resolved the bug with RemoveUnsuitableExtension + dyna_state
- Removed comments of explanation + log_debug warning
- Set extension to be disabled if customBorderColorWithoutFormat is not available
- Helps to solidify the removal of bans in vendor drivers
This changes fixes the VUID 04015 for the handling with undefined format and made the usage of the extension more near to what Vulkan specification expects, yet there is still cases where we can't emulate properly samplers and some translucid black boxes will still appear, yet, now alleviated by allowing extension choose the proper custom available in Vulkan or degrade into a fallaback of solid colors.
-> Adjustment of VK_EXT/KHR_robustness2: This feature was introduced in ExtendedDynamicState refactor (#3074), as safety measure for descriptors during the Write of buffers, providing robustness with an upgraded access to image, buffers and proper discard of null data in descriptors, however, despite the configuration the logs during debug sessions never stopped to bring the next VUID-VkWriteDescriptorSet-descriptorType-00324 and VUID-VkWriteDescriptorSet-descriptorType-00325, being the first one, the most constant issue plaguing logs; the approach was not only ensuring device can access between each of the version of this feature, whether is an EXT or KHR (drivers can report one of them or both, yet, if we call the one of them and it's not the version supported, driver would not load the feature, there's a priority to the KHR version) with a simplified configuration of the extension to use only nullDescritor to deflect properly buffers and other trash data outside of descriptors bound; ensuring to wire the path when it's and not available and also with BindVertexBuffers2EXT when it's or not available; fixing both VUID's. This changes helps to save some CPU resources and memory on binding routes.
- Fixes VUID-VkWriteDescriptorSet-descriptorType-00324
- Fixes VUID-VkWriteDescriptorSet-descriptorType-00325
- Fixes VUID-vkCmdBindVertexBuffers-pBuffers-00621 (alongisde a latter adjustment for pStrides)
-> Adjustment VK_EXT_image_robustness: As other features, this was implemented during the ExtendedDynamicState refactor (#3074), currently this change it's just to ensure more drivers are accessing this feature by changing the modality from extension to an explicit feature, some other redundant code was cleaned within this change.
-> Restored gating flush operation on removed gpu accuracy: An issue report from an user called CaptFaraday in https://github.com/eden-emulator/Issue-Reports/issues/425, posted a behavior appearing after the rework of gpu accuracy levels (#3129), which broke the rendering in Paper Mario - The-Thousand-Year Door where some graphical issues such as black flash and missing rendering from many animations through the game thanks to the removal of the flush inside FlushAndInvalidateRegion gated with IsGPULevelExtreme and suggested a possible fix with resting the missing gating and flush; which I did and properly restoring the complete behavior of this functionality + wiring to the new IsGPULevelHigh for a better semantic correctness, the change was tested and didn't affected Yoshi's Crafted World graphical problems and main reason behind the deletion of this function, fixed in fcfcee7247.
- Solves https://github.com/eden-emulator/Issue-Reports/issues/266
- Solves https://github.com/eden-emulator/Issue-Reports/issues/425
- Fixes Paper Mario - The-Thousand-Year Door
- Keeps Yoshi's Crafted World issue still fixed
-> Adjustment VK_EXT_conditional_rendering: Yuzu inherited us in their Vulkan backend multiple flaws which got worsened with the time as game and drivers changed, aside that, with the time studying this source code and especially the Vulkan-side of Eden, I started to learn and recognize some extensions that required a wide and robust modification to ensure the logic of the extension works as intended; currently ConditionalRendering had a lot of minimal modification:
- Reordering the functions from "_NotifySegment_" to avoid a masive ram leak coming from query_cache (@weakboson) (#131)
- Removing a function "_NotifySegment_" from rasterizer to ensure Metroid Prime 4 stopped crashing due to serious ram leaks in query_cache (@Maufeat) (#3142)
And other intents to make ConditionalRendering fully working, such as happened in ExtendedDynamicState refactor (#3074) but only patched an horrible situation with how the extension was truly working, after spending more than 3 months studying how this and other sub-sequential and essential extensions touched in this PR worked in Vulkan, I dived once again to make it work properly; one of the first changes was to fix an invalid reference lookup of queries, which fixed the removal of "NotifySegment" inside rasterizer and start to adjusting other parts of the implementation of ConditionalRendering minimally and switching with heavy tests to ensure not a single game gets broken among the changes; yet the initial benefits from fixing the indirection in the lookups to query cache, was to reduce the amount of time of GPU was spending in the constant state of queries, which proved to reduce flickering in Pokémon ZA among others, with also an small increase of performance but more noticeable stability, starting to reduce stutering bit by bit.
This advances allowed me to fix one of the the functions of IsGPULevelHigh, where existed a bypass to accelerate conditional rendering without the proper checks if the extension was truly supported, freeing QCOM from the flag of a fixated presync workaround; which also improved the usage of QCOM driver for 8 Elite devices and Unreal Engine 4 - 5 games, such as Dragon Ball Z - Sparking Zero; but that's not the only benefit from the current tries to make ConditionalRendering implementation more robust and accurate to specifications, but also started to show key points of where VK_EXT_transform_feedback was also failing to work properly.
-> Adjustment VK_EXT_transform_feedback: Like many other features in this PR, this one was also adjusted minimally in ExtendedDynamicState refactor (#3074), with the ConditionalRendering refactor going on, the solutions for the usage of this extensions started by ensuring each key function is properly gated by a getter which would only be enabled if the extension was already being loaded in the virtual device, if wasn't the case I was making sure to wire the fallback correctly, which wasn't in place and didn't had a robust handling since ever, this way games started to not only improve graphical accuracy, like some games such as Zelda - Echoes Of Wisdom where the lightning and dark border moves/ reacts dynamically.
Besides that, this change brought the possibility to finally get rid of the indirection of the buffers synchronization which often take a non-synchornization path to ensure a faster reply but with higher possibilities to cause graphical issues in among several games; aside that, also helped to ensure "_query_cache.CounterEnable(VideoCommon::QueryType::StreamingByteCount, false)_;" function is properly allocated and reset in a different place than where this was placed.
- Maintain Metroid Prime 4 fixes even after returning the lines that caused the game to be unplayable, whether was an instant crash
or crash after some minutes of gameplay, fixes that were introduced in other work (#3142).
Within the first step in the refactor of this extension, this work was reviewed by @wildcard which made me notice of an issue of handling inside buffers, there existed a mismatch on the tracking of feedback buffers and since we're treating them as buffer_slot, counterstream was still tracking and consuming stream_buffers and not where data was really passing through; derivating the counter selection of counterBufferCount by stream indexes and not by slot, which could cause cases of _Stream =! slot_, a solution proposed for me was to add stream mapper function where the stream slot were located + updating UpdateBuffers() to calculate buffer counts per slot and not stream, allowing to fully map the map funtion of stream mapper; along other changes on the WriteBuffers + ProduceBufferCounter to avoid any misaligment.
-> Other minimal adjustments: Alongside these important adjustment, others were also made to ensure logical coherency to this recent changes, such as ensuring FullSynchronization of buffers path, since GPU has mostly a syncing issue with certain type of textures and vertex calculations, the original behavior of jumping into a non-synchronize path of buffers let GPU ran without proper awareness of the textures being loaded, ensuring more performance if all the textures reached properly inside GPU, but with no safety provided for buffers, even we added a cases were dummies and mostly buffer trash data gets discarded by nullDescriptors, this won't ensure graphical artifacts or a bad calculation on the range of lightning/ gfx could appear. I dare to think this was thought to be implemented due to the original heavy costs on Yuzu's time, this along the removal of QCOM's drivers from Query's Presync funtions.
A small adjustment to the mutable functions inside the CreateImageView structure to add the extended usage:
"Because Switch's GPU creates incompatible views (sRGB and UNORM) on the same image. A sRGB image can't be used as storage but it is in a UNORM view. Which is exactly the use case of these flags." - @weakboson
During all of this changes inside queries, we started to get in some devices "Device Loss" warning from Vulkan along 2 specific warnings:
- [ 102.384895] Render.Vulkan <Critical> video_core/vulkan_common/vulkan_debug_callback.cpp:69:DebugUtilCallback: vkDeviceWaitIdle(): THREADING ERROR : object of type VkQueue is simultaneously used in current thread 517024609280 and thread 517864567808
- [ 114.003530] Render.Vulkan <Critical> video_core/vulkan_common/vulkan_debug_callback.cpp:69:DebugUtilCallback: vkCmdBeginQuery(): VkQueryPool 0x15e400000015e4 and query 172: query not reset. After query pool creation, each query must be reset (with vkCmdResetQueryPool or vkResetQueryPool) before it is used. Queries must also be reset between uses.
Since before all of this adjustments, original GPU thread often take it's time to stop and look for a moment to synchronize with CPU (non-TimelineSemaphore), the whole flow data was improved that we were producing more data stale than we could really take due to the lack of a Reset to avoid pools being filled with old data, in order to get rid of this, another try to implement ResetQueryPool's appeared which was intented to be implemented some months ago and got removed in #3270, this time aligning the vkDeviceWaitIdle + ResetQueryPool was proved to be effective than first implementation and didn't caused major issues, now GPU can Vulkan can reset staling data, which can catalogued as old once they were used and displayed in frame, keeping a more fluid exchance and discard of data.
- Fixes VUID-vkCmdBeginQuery-None-00807
- Fixes multithreading error with vkDeviceWaitIdle and data allocation
We have some other changes to the coherency of ExtendedDynamicState2 and the feature of restart primitives, which now patches topologies once are processed if they pass through ExtendedDynamicState2 enabled and get reset before every draw to prevent another topology VUID; also I ensured refresh, reset, clamp and overall improve the math inside the Viewport/ Scissor feature operations inside DynamicState and later upgrades.
---------------------------
UPDATE (23/04/2026): After passing a heavy testing phase, an issue was encountered with AMD drivers on Windows which based on the commit: c07dfa6fb4, Super Mario Odissey started to show vertex glitches on the the waterfall + water fog being rendered incorrectly, if VertexInputDynamicState was disabled caused black screen on ExtendedDynamicState (1 - 3) and hard crash if ExtendedDynamicState it was disabled; this situation was caused to the vertex input dynamic tied to ExtendedDynamicState1, AMD driver didn't allowed fast access to BindVertexBuffers2EXT without binding strides first, which caused a syncing problem between the binded vertex and the missing buffer in the same chain, this got fixed by removing the conditions for vertex input dynamic.
Aside that; another pair of issues were addressed in the meantime of refining this PR, one of them was to solve the failing BGR565 formats to swizzle into RGBA5 which allows to swap between red and blue; solving the inverse situation of blue icons on Mario Kart 8 Deluxe for older QCOM drivers and SoC's, such as Snapdragon 855 - 870; which will also help some Exynos processors to render properly. This solution was converted into a toggle/hack because it's use it's very conditional on older hardware; newer SoC's such as 8 Elite won't longer require this handling to convert properly BGR565 texture even if the support for the format is not available.
---------------------------
Here an small preview of what this pr has been fixed so far, but our testing range may be more limited than what this can actually do:
- Allow to display new effect on games
1. Jump Force: New particle on stages and main menu.
2. The Legend Of Zelda - Echoes of Wisdom: darkness post processing effect on screen filter such as game intro and smokes on houses (8 Elite).
3. Reduce texture flickering on games such as EoW, Monster Hunter Rise.
4. Improved performance stability on various games with Android.
5. Improved Xenoblade games rendering with QCOM stock drivers by improve viewpoint handling (8 Elite).
6. Fixes vertex explosion on Xenoblade 3 with AMD GPU with extended dynamic state enabled.
7. Fixed Mario Kart 8 Deluxe rendering with VK_EXT_vertex_input_dynamic_state enabled.
8. Fixes certain angle of Pokemon Legend Z-A would look mono color with vertex input dynamic state.
9. Fixed graphical issue with VK_EXT_vertex_input_dynamic_state on mobile drivers.
10. Fixed vertex explosion with Turnip (8 Elite) on The Legend Of Zelda- Breath Of The Wild during loading screen.
11. Fixed issue of vertex on Pokémon Legends ZA with VK_EXT_vertex_input_dynamic_state enabled.
12. Improved rendering and stability of Inmortal Fenyx Rising, including QCOM drivers being able to reach into gameplay.
13. Fixes Paper Mario - The-Thousand-Year Door missing rendering on animations through the whole game.
14. Fixed Mario Kart 8 Deluxe blue tint icon on Snapdragon 855 - 870 (by enabling Emulated BGR565 hack toggle).
15. Fixed Naruto Ultimate Ninja Storm issue rendering on characters like Naruto being blue on older QCOM SoC's and Exynos (by enabling Emulated BGR565 hack toggle)
16. Fixed Dangaronpa Killing Harmony v3 issue rendering on characters with blue tint on older QCOM SoC's.
---------------------------
_**Special Thanks - Credits**_
-> @Gidoly for being able to keep track of the intensive testing phase this pr required and the will to keep helping in development, you're a good friend and very useful.
-> @CaptFaraday for the suggestion of the fix for Paper Mario.
-> @wildcard for the review during the refactor of VK_EXT_transform_feedback, without this comment I would probably ran into many untrackable issues.
-> @weakboson for the suggestion into the solution for sRGB's and UNORM's in the incompatible views.
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3853
Reviewed-by: crueter <crueter@eden-emu.dev>
push %edx is not what i wanted, nor what anybody wants, xbyak silently accepting this before was not intended
now that xbyak is updated this is an issue
the issue was simply:
a) ptr being overwritten (if it happened to be EDX/EBX/EAX) due to changed WAITPKG logic (oops)
b) xbyak not reporting wrong r32 pop/push on older versions thus missing it and now it throws an exception
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3875
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
## Summary
This change hardens Android Picture-in-Picture handling to avoid runtime crashes on devices/ROMs where PiP APIs are unavailable or behave inconsistently.
## What changed
- Added a feature gate for PiP support using `FEATURE_PICTURE_IN_PICTURE`.
- Early-returned from PiP flows when unsupported.
- Wrapped PiP API calls (`enterPictureInPictureMode`, `setPictureInPictureParams`) in guarded handlers that catch `IllegalStateException` and `UnsupportedOperationException`.
- Logged one warning per failed PiP action to avoid log spam.
## Why
On some Android devices, calling PiP APIs can throw at runtime even when the app is otherwise functioning normally. This patch prevents those calls from crashing/interrupting emulation and keeps behavior unchanged on supported devices.
## Notes
- No behavior changes for fully PiP-capable devices.
- Safe no-op on unsupported devices.
Co-authored-by: Nikolai Trukhin <coolone.official@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3647
Reviewed-by: DraVee <chimera@dravee.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
intended to fix two bugs identified by Pavel upon android shortcut launching (and prolly all FEs since the rely on intent launching too):
1. external content not loading: fixed by running restoreContentForGame for per game mount in content path.
2. custom settings no loading: that was proven to be user side, but adjustments were made to match normal launch.
should be harmless for normal usage. once validated can be merged.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3854
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Co-committed-by: xbzk <xbzk@eden-emu.dev>
Just discovered that stock adreno drivers on a730 had no Immediate VSync mode available, and it was falling back to FIFO, which causes a lot of response delay in Unity games.
But if someone chose Immediate, it prefers low latency above buffering, so Mailbox is his friend, and FIFO is his nemesis.
So i just changed Immediate to fall back to Mailbox first, and only if Mailbox is not available either it falls back to FIFO:
Immediate -> Mailbox -> FIFO;
Mailbox -> FIFO;
FIFO Relaxed -> FIFO.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3746
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Co-committed-by: xbzk <xbzk@eden-emu.dev>
This pr aims to make a first step into giving Eden's Vulkan backend maintenance with better formatting, understanding and reduce the redundancy between some wrong implementations:
-> ProvokingVertex: Has been reworked completely, now the wiring to ExtendedDynamicState3 (ProvokingVertexMode) it works safe, the gating of the extension no longer requires user enabling on UI, it will be enabled automatically based on what features of the extension are available on driver, depending if first or last mode are available and also will be properly set under TrasformFeedback operations; this way we're gonna ensure all drivers, including Android stock drivers on QCOM, Mali and other mobile vendors drivers access correctly to the extension, fixing some graphical issues (flickering textures or wrong sccisors on vertex that required first mode) generated by the missing first mode handling or the proper clearing on pipeline state. This change will increase/ decrease slightly the performance on some games that changes dynamically between first and last modes, but will also ensure a clear path to GPU to use resources smartly, reducing VRAM consumption in PC and MEM/GPU percentage of use on Android (marginal to 5 - 8% approx).
-> Removal VK_EXT_multi_draw: It has passed some months since the first try to implement this feature, but wasn't completed so functionality was null to negative, taking space in source and using small CPU cicles for initialization during device creation that reduced CPU effectiveness by 2 - 5%, aside that, after reviewing the situation of formally introducing handling for multidraws to reduce the floods of constants draw calls into 1 per batch, seems to not pay the overhead when the multidraw capacity is less or equal to 1, aside that, for the time being batching multidraws will introduce indirections on each batch of command draws, that graphical issues will appear and reducing performance can happen, something it was gonna solve. For the time being it's discarded, but, may be analyzed the chance to introduce it properly in a later date.
-> Removal VK_EXT_indexing_descriptor: Currently the implementation of this feature was partial, with not proper handling on layouts; just the initial checks on device creation and chained up to the pNext feature, currently this extension will require a buffer cache and texture cache rework to set layouts and reduce the amount of use of descriptor into making it a less expensive cost effective, aside that to generate a path for the Bindless Texture and Bindless Buffer, allowing to track state of textures in runtime and ensuring the state of some compiled shaders doesn't change if it's no needed, among other benefits, besides that, enabling this feature was only generating innecessary checks on GPU, so consumption would be higher than it should be.
-> Removal of VK_EXT_swapchain_maintenance1: The use of this feature was really conditional to certain support on newer drivers and cards, which wasn't available for all platforms, I concluded that if the support for this instance wasn't really there, the cost effective between the try to initialize it and running it, won't be good as when it didn't exist on our Vulkan device, with also the constant factor of not being completely implemented, right now I'm aiming to reduce the complexity on Vulkan side to keep it as simple as it could for a future video_core rework, which may start somewhere these weeks.
-> Refined the Maintenance features: Meawhile this features are usually inherent to Vulkan core functionality, sometimes drivers doesn't expose them well, which leads to Eden run Vulkan without really noticing the existence of maintenance features on driver to improve stability, so we're tied to declare them and load them when a device creation starts by asking if driver supports and which, currently 1 - 5 are core maintenance features, meanwhile the 7 - 9 are more experimental and not being available everywhere, so right now to help drivers give attention to this features we not only load them, but also calculate with features bits which features inside Maintenance5 are available to use, that was the initial purpose, but we weren't using the full potential of the extension; I made cleaned part of the unneeded log code for the initialization of this Maintenance5 and it's feature flags, but also making an operation to sanitize depth/ stencil when One is not available in swizzle operations, making it easier to draw it; it's also needed to mention that Maintenance9 was removed from source code until we can have better handling on Arrays2D, aside that, the use of the extension was really conditional to certain drivers being capable of use it, so I remove it.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3839
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Co-committed-by: CamilleLaVey <camillelavey99@gmail.com>
This pr content and goal is to provide following to Eden's user base issues with settings, adjust default values on settings and refactor some handlings to improve the plug-and-play factor:
-> Combo-box for ASTC Recompression Method Removed: The removal of this toggle was due to the redundant process inside Android devices, most drivers do suppot ASTC handling natively and meanwhile this option provided some benefits to some older Mali devices, the specifications from those and the real compatibility doesn't pay the need for this setting, unless something else is provided to be wrong, the default setting will be uncompressed and no longer available in UI to change. Removed some dead code along with it.
-> Removal of ASTC Decode Method ifdef block for Android: Since Yuzu's, the handling for this option was strangely set on CPU, having a specific block for Android in settings, possibly due to the constant spikes on GPU usage that wouldn't be good to load GPU with the whole flow of operations; but since then and until today, Eden's constant effort to make operations more accurate and smartly resolved, have marked the difference that now CPU default on Android no longer provides the benefit to relief GPU stress than reducing performance in some heavy draw commands on some games; the default will be set to GPU to keep parity with PC configuration aiming for a global configuration with all platforms. The setting will be kept to user range, unless is proved to no longer be needed, right now low end devices could still have benefit from CPU/Async, but requires testing from community to show real potential.
-> Adjusted default value of ExtendedDynamicState: Currently we're facing some issues of logic inside of ExtendedDynamicState implementation, that makes it a bit unstable when it comes to use the disabled mode, right now we jump to ExtendedDynamicState1 for more stability, meanwhile we fix the remaining issues in future updates (currently one fix will be presented - or would be merged along this pr, the 1st Global Vulkan Maintenance which has some fixes for this situation), so stock drivers and other mobile drivers will behave and benefit from this.
-> Exposed hidden and defaulted settings to user's UI: Yuzu implemented some settings that were available on PC's UI but weren't presented on Android's UI or wasn't something expected to do, either way there are some strange behaviors due to this default settings and each of them do something different, i'm not gonna dive into a deep explanation, but to make it short, they stablish asynchronous operations for GPU operations, like Async GPU Emulation (to use a CPU thread to boost performance with GPU emulation, currently a performance hack), Asynchronous Vulkan Presentation this does something a like to disperse draw's/ syncing from TimelineSemaphores and set a thread of CPU to help in running some Vulkan operations (another performance Hack), meanwhile most of the Desktop drivers are mostly nice with this setting, Nvidia aren't due to the nature of the hack, so provokes black screen or failing into initialize games. Mostly Asynchronous operations are fast-paths/ hacks to improve performance to the cost of some graphical issues like the pop-in with Asynchronous Shader Building during the shader compilations, sometimes the trade-off could give random crashes and other issues. Android it's not the exception and currently by disabling GPU Async Emulation user's will be able to fix some strange flickering on Zelda - Link's Awakening (NCE) and other games suffering from similar issues, may also fix random crashes on games that are supposed to work. These settings will be exposed for a short amount of time, meanwhile I receive feedback of the usefulness of having them active or the whole operation being used on Android, aside that, disabling them or one of them will inevitable reduce performance a bit, not so notorious, but it will be up to user's decision now to use them or not.
-> AMD FidelityFX's Super Resolution UI handling (a personal request): Now the slider default value will be 0% and will only appear whenever FSR is choosed among other window adapting filters, this will also work with the quick setting menu during runtime.
-> Fixed the issue of changing drivers removing all games compiled shader cache: Currently our implementation to safeguard users from unknown issues when a different driver tries to load/ read compiled shaders from another version of Turnip/ QCOM driver, that will delete shaders if the driver is removed or changed; deleted all games compiled shader cache, which increased the annoyance on Android users along with adding unneeded complexity, this used to happen whenever a driver was changed in global settings or per-game settings. Now no longer will happen if the driver is changed on global settings and changing drivers in per-game configuration will only delete current game where the driver was change without affecting others, from here, I'll apologize for this unneeded situation.
-> Refactored the input controller detection (another request of mine, hehehe...): This implementation will work to reduce the burden on a new installation (since I have to test everything personally, cuz testers are lazy ass mfs), the input detection is now more accurate to what kind of input a device has, whether is in-built or wireless gamepad, will map it once Eden detect's physical input by reading the controllers inputs that OS provides natively and set or disable touchscreen controllers automatically:
- If in-built is detected (Ayaneo, Ayn, Retroid or any Android handheld), Eden will map it automatically and will disable touchscreen controller.
- If Wireless gamepad is detected, the same behavior as described above will happen with the extra to recover touchscreen controller whenever the gamepad goes off.
It was quite funny to do this, cuz Xiaomi and some other manufacturers always do strange shenanigans with how the inputs are detected (wasn't funny).
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3832
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Co-committed-by: CamilleLaVey <camillelavey99@gmail.com>
For some unknown reason, bundled OpenSSL likes the `https` scheme,
whereas system OpenSSL (on Gentoo at least) does not... even when the
bundled OpenSSL is built exactly like the Gentoo one, certificate and
all...
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3843
Closes#3707
All this does is anchor the left and right-most cards to their
respective edges, and then equally distributes the gaps between cards
thereafter.
Don't even bother trying to figure out what the hell I just wrote. I'm a
UI designer, not a mathematician.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3829
+# master project detection--useful for FetchContent/submodule inclusion
+set(master_project OFF)
+set(subproject ON)
+
+if (NOT DEFINED PROJECT_NAME)
+ set(master_project ON)
+ set(subproject OFF)
+endif()
+
project(spirv-tools)
# Avoid a bug in CMake 3.22.1. By default it will set -std=c++11 for
@@ -135,46 +144,49 @@ if (DEFINED SPIRV_TOOLS_EXTRA_DEFINITIONS)
add_definitions(${SPIRV_TOOLS_EXTRA_DEFINITIONS})
endif()
-# Library build setting definitions:
-#
-# * SPIRV_TOOLS_BUILD_STATIC - ON or OFF - Defaults to ON.
-# If enabled the following targets will be created:
-# ${SPIRV_TOOLS}-static - STATIC library.
-# Has full public symbol visibility.
-# ${SPIRV_TOOLS}-shared - SHARED library.
-# Has default-hidden symbol visibility.
-# ${SPIRV_TOOLS} - will alias to one of above, based on BUILD_SHARED_LIBS.
-# If disabled the following targets will be created:
-# ${SPIRV_TOOLS} - either STATIC or SHARED based on SPIRV_TOOLS_LIBRARY_TYPE.
-# Has full public symbol visibility.
-# ${SPIRV_TOOLS}-shared - SHARED library.
-# Has default-hidden symbol visibility.
-#
-# * SPIRV_TOOLS_LIBRARY_TYPE - SHARED or STATIC.
-# Specifies the library type used for building SPIRV-Tools libraries.
-# Defaults to SHARED when BUILD_SHARED_LIBS=1, otherwise STATIC.
-#
-# * SPIRV_TOOLS_FULL_VISIBILITY - "${SPIRV_TOOLS}-static" or "${SPIRV_TOOLS}"
-# Evaluates to the SPIRV_TOOLS target library name that has no hidden symbols.
-# This is used by internal targets for accessing symbols that are non-public.
-# Note this target provides no API stability guarantees.
-#
-# Ideally, all of these will go away - see https://github.com/KhronosGroup/SPIRV-Tools/issues/3909.
-option(ENABLE_EXCEPTIONS_ON_MSVC "Build SPIRV-TOOLS with c++ exceptions enabled in MSVC" ON)
-option(SPIRV_TOOLS_BUILD_STATIC "Build ${SPIRV_TOOLS}-static target. ${SPIRV_TOOLS} will alias to ${SPIRV_TOOLS}-static or ${SPIRV_TOOLS}-shared based on BUILD_SHARED_LIBS" ON)
style="opacity:1;mix-blend-mode:normal;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:10.8382;stroke-opacity:0.566238;paint-order:stroke fill markers"
id="circle18"
cx="-246.8315"
cy="246.8338"
inkscape:label="Circle"
r="191.89999"/>
</clipPath>
<clipPath
clipPathUnits="userSpaceOnUse"
id="clipPath22">
<circle
style="opacity:1;mix-blend-mode:normal;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:10.8382;stroke-opacity:0.566238;paint-order:stroke fill markers"
style="display:inline;mix-blend-mode:normal;fill:url(#linearGradient35);fill-opacity:1;fill-rule:nonzero;stroke:#320081;stroke-width:4.067;stroke-dasharray:none;stroke-opacity:1;paint-order:stroke fill markers"
inkscape:label="Circle"
d="M 256,2.2792898 A 254.0155,253.71401 0 0 0 150.68475,25.115202 c 19.54414,1.070775 38.74692,5.250294 51.56848,11.647658 14.14361,7.056691 28.63804,19.185961 39.4212,29.347551 h 40.60981 c 1.03847,-0.68139 2.10297,-1.36938 3.1938,-2.05957 5.45602,-15.78533 14.79164,-43.183497 19.49612,-57.0097682 A 254.0155,253.71401 0 0 0 256,2.2792898 Z m 61.57106,7.567234 -18.26098,46.1544672 c 7.79702,-4.13918 16.35655,-7.87447 25.20671,-10.87081 23.1229,-7.828433 43.96931,-10.170904 54.94058,-10.868226 A 254.0155,253.71401 0 0 0 317.57106,9.8465238 Z m 65.39277,26.4001532 c -9.68256,4.806644 -33.05532,16.642034 -55.68217,29.863734 H 424.4677 A 254.0155,253.71401 0 0 0 382.96383,36.246677 Z M 113.90698,45.690231 A 254.0155,253.71401 0 0 0 87.532302,66.110411 H 194.2739 c -1.47402,-0.80231 -2.35141,-1.25949 -2.35141,-1.25949 l 10.4496,-11.83348 -38.40568,7.01234 c 0,1e-5 -12.21537,-4.60266 -40.17313,-12.27223 -3.45336,-0.94731 -6.75329,-1.61824 -9.8863,-2.06732 z m -36.803618,30.18635 a 254.0155,253.71401 0 0 0 -34.88372,43.090929 h 59.976738 c 18.11461,-12.04145 40.14252,-22.882149 62.31266,-24.534159 52.93006,-3.9444 70.16538,1.86342 70.16538,1.86342 0,0 -4.612,-4.8206 -14.51938,-13.36656 -2.72366,-2.34942 -6.0844,-4.77373 -9.52455,-7.05363 z m 174.472868,0 c 4.57322,4.7186 7.29716,7.83565 7.29716,7.83565 0,0 3.53501,-3.18484 9.62532,-7.83565 z m 60.27649,0 c -21.56573,15.45339 -25.4703,27.979669 -25.4703,27.979669 0,0 54.83326,-19.215729 100.70543,-0.31228 11.63986,4.79661 21.58481,10.13159 29.94832,15.42354 h 52.74419 A 254.0155,253.71401 0 0 0 434.89664,75.876581 Z M 36.250648,128.73367 A 254.0155,253.71401 0 0 0 16.372095,171.82459 H 147.45478 c 1.45695,-2.5815 3.06539,-5.08648 4.83979,-7.48982 14.23694,-19.28301 27.92088,-30.0088 36.86047,-35.6011 h -30.25323 c -5.87346,0.93472 -12.04945,1.99094 -18.28166,3.16937 -30.12936,5.69727 -81.157618,22.78945 -81.157618,22.78945 0,0 11.47125,-12.39249 29.11369,-25.95882 z m 265.630492,0 c 33.48676,11.2434 52.42799,26.78443 62.7752,43.09092 h 130.97157 a 254.0155,253.71401 0 0 0 -19.87856,-43.09092 h -44.81136 c 14.85233,11.5863 21.59948,20.9854 21.59948,20.9854 0,0 -33.5226,-12.37087 -66.0646,-20.9854 z m -45.96641,16.27007 c -1.00419,0.0106 -10.12705,0.72026 -44.98966,20.64729 -3.12132,1.78406 -6.25434,3.86182 -9.37468,6.17356 h 41.81911 c 7.17181,-17.34774 12.64083,-26.82085 12.64083,-26.82085 0,0 -0.0287,-7.1e-4 -0.0957,0 z m 14.18088,0.0465 c 0,0 -3.31228,9.32762 -7.30492,26.77438 h 51.78554 C 287.6577,146.14158 270.09561,145.0502 270.09561,145.0502 Z M 13.152456,181.59075 A 254.0155,253.71401 0 0 0 3.927651,224.68167 H 134.1447 c 0.56161,-12.72411 2.67825,-28.50188 8.61499,-43.09092 z m 176.661504,0 c -14.27121,13.10564 -27.60733,29.58761 -37.56073,43.09092 h 73.3721 c 4.47018,-16.79061 9.35068,-31.26371 13.86562,-43.09092 z m 70.85787,0 c -2.41384,11.76417 -4.9032,26.20707 -6.94831,43.09092 H 360.4832 c -8.32133,-10.88917 -20.66988,-26.17008 -36.35141,-43.09092 z m 109.17313,0 c 6.63611,15.24089 6.92441,30.5373 5.57882,43.09092 h 132.64857 a 254.0155,253.71401 0 0 0 -9.22481,-43.09092 z M 2.90181,234.44783 A 254.0155,253.71401 0 0 0 1.984498,255.9933 254.0155,253.71401 0 0 0 2.90181,277.53876 h 211.89923 c 2.25762,-15.52555 5.14325,-29.93448 8.3385,-43.09093 h -77.8863 c -6.46396,9.27617 -10.33076,15.56549 -10.33076,15.56549 0,0 -0.82623,-6.14945 -0.9354,-15.56549 z m 249.72093,0 c -1.3692,13.09684 -2.4456,27.49209 -3.02068,43.09093 h 259.49613 a 254.0155,253.71401 0 0 0 0.91731,-21.54546 254.0155,253.71401 0 0 0 -0.91731,-21.54547 H 374.02584 c -0.445,2.5469 -0.90878,4.89768 -1.32817,7.01751 0,0 -1.69726,-2.53821 -4.94056,-7.01751 z M 3.927651,287.30493 a 254.0155,253.71401 0 0 0 9.224805,43.09091 H 214.04393 c -1.29238,-15.40742 -1.57503,-30.04388 -0.41861,-43.09091 z m 245.385009,0 c -0.30355,13.54349 -0.22032,27.92598 0.36951,43.09091 h 249.16537 a 254.0155,253.71401 0 0 0 9.22481,-43.09091 z M 16.369511,340.16201 a 254.0155,253.71401 0 0 0 19.878554,43.09091 H 221.4677 c -2.69781,-14.4523 -4.96108,-29.01285 -6.4832,-43.09091 z m 233.842379,0 c 1.15864,15.47765 3.81286,29.83979 7.51679,43.09091 h 218.02325 a 254.0155,253.71401 0 0 0 19.87856,-43.09091 z M 42.217052,393.01909 a 254.0155,253.71401 0 0 0 34.88372,43.09093 H 233.09561 c -3.40902,-13.67281 -6.76794,-28.2531 -9.73902,-43.09093 z m 218.490958,0 c 5.34985,16.15926 12.22007,30.51982 19.68733,43.09093 h 154.50389 a 254.0155,253.71401 0 0 0 34.88371,-43.09093 z M 87.529722,445.87618 a 254.0155,253.71401 0 0 0 166.229968,63.8208 c -3.67805,-12.0825 -10.85464,-35.49828 -18.18088,-63.8208 z m 199.010328,0 c 17.5887,26.43772 36.99259,43.60598 47.33592,51.61309 a 254.0155,253.71401 0 0 0 90.59431,-51.61309 z"/>
<path
id="path27"
style="display:inline;mix-blend-mode:multiply;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:none;stroke-width:3;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;paint-order:stroke fill markers"
4. Put `"C:/Program Files/Microsoft Visual Studio/18/Community/VC/Tools/Llvm/x64/bin/clang-cl.exe"` as your C/C++ compiler path.
5. Open `Visual studio > Open project` or Solution > Change to search for the CMake project file (`CMakeList.txt`) file on the cloned directory, and then build.
-`CPMUTIL_FORCE_SYSTEM` (default `OFF`): Require all CPM dependencies to use system packages. NOT RECOMMENDED!
- You may optionally override this (section)
-`CPMUTIL_FORCE_BUNDLED` (default `ON` on MSVC and Android, `OFF` elsewhere): Require all CPM dependencies to use bundled packages.
-`CPMUTIL_PATCH_DIR` (default `${PROJECT_SOURCE_DIR}/.patch`): Path to patches used in packages. Stored as `<PATCH DIR>/json-package-name/0001-patch-name.patch`, etc.
-`CPM_SOURCE_CACHE` (default `${PROJECT_SOURCE_DIR}/.cache/cpm`): Where downloaded dependencies get stored.
## About
CPMUtil works by defining dependencies in a JSON file, `cpmfile.json`, and calling `AddJsonPackage`. These dependencies generally must define, at minimum:
- The repository and Git host
- A release artifact, commit, or tag archive to download
- A SHA512 sum for the downloaded artifact
And may optionally define other properties like:
- The minimum version for system packages
- The package name used for system packages (this defaults to the json key if undefined)
- Searches for a system package named `fmt` of version 8 or higher
- If found, uses the system package and caches it for future use
- If not found:
- Downloads fmt 12.1.0 from the GitHub Archive into `.cache/cpm/fmt/12.1.0`
- Verifies the hash
- Applies the `0001-disable-reference-copy.patch` patch to the source tree
- Sets `FMT_TEST` to `ON`
- Adds the downloaded directory to CMake
- Now, future `find_package(fmt)` calls will use the downloaded package
There are two types of packages CPMUtil can define: standard and prebuilt CI packages. Some properties are common to both types, however.
## Common Properties
These JSON properties are used by standard and CI packages alike.
-`package`: The package name used by `find_package` to check for the existence of a system package.
- If unset, defaults to the JSON key
-`repo`: The Git repository the package is stored in, if applicable.
-`version`: The version of the package to download. This is required.
-`min_version`: The minimum required version of the package, if a system package is desired.
-`git_host`: The Git host the package is stored in, if applicable. Defaults to `github.com`.
## Standard Packages
Normal packages, like the prior `fmt` example, *must* also define:
-`hash`: The SHA512 hash of the downloaded artifact. CPMUtil generally computes this for you.
- A valid version/URL identifier:
-`url`: Download from a raw URL.
-`sha`: A short or fully-qualified Git commit sha. CPMUtil recommends using 10-character wide shas.
-`tag`: A Git tag. See [Versioning](#versioning) for its relation to `version`.
-`artifact`: A GitHub/Forgejo/Gitea release artifact (requires `tag`). See [Versioning](#versioning) for its relation to `tag` and `version`.
The following are optional to define:
-`source_subdir`: A subdirectory containing the `CMakeLists.txt` to configure a project. Useful for projects like `zstd`.
-`bundled`: Force the usage of a bundled package. Useful for packages where the system package is broken or nonexistent; e.g. including external fragment shaders.
-`find_args`: Additional arguments passed to `find_package`, e.g. `MODULE`
-`patches`: Array of in-tree patches to apply to the downloaded source code. See [#Patches](TODO).
-`options`: Array of CMake options to apply before configuring the package, e.g. `"FMT_TEST ON"`.
### Versioning
When using tags or artifacts, it may be cumbersome to repeat the version multiple times; especially if it's constantly changing. For this purpose, `tag` and `artifact` both support basic version text replacement.
`tag` can use `%VERSION%` to have its version replaced with the `version` defined for the package, e.g. for OpenSSL; when downloading, `tag` will evaluate to `openssl-3.6.2`:
```json
"openssl":{
"repo":"openssl/openssl",
"version":"3.6.2",
"tag":"openssl-%VERSION%"
}
```
`artifact` also supports `%VERSION%` replacement, and can also use `%TAG%` to be replaced by the computed tag. Take this Boost definition:
```json
"boost":{
"repo":"boostorg/boost",
"tag":"boost-%VERSION%",
"version":"1.90.0"
}
```
Boost's artifact for this version is stored in `boost-1.90.0-cmake.tar.xz`. Notice that the computed tag,`boost-1.90.0`, is in the name of the artifact! Thus, `artifact` can be either:
-`boost-%VERSION%-cmake.tar.xz`
- Or, even simpler: `%TAG%-cmake.tar.xz`
Future updates need only change the `version` identifier, and the artifact and tag will automatically be updated!
### Patches
CPMUtil is able to apply in-place source tree patches to downloaded packages. These are defined in JSON as an array of names, preferably using `git-format-patch`'s scheme of `<4 digit number>-patch-name.patch`. These are stored in `<CPMUTIL_PATCH_DIR>/<json-key>` (remember that `CPMUTIL_PATCH_DIR` defaults to `$ROOT/.patch`); e.g. `boost` patches would be in `.patch/boost`. Let's say we've made three patches and want to add them; in the Boost JSON definition, we would add:
```json
"patches":[
"0001-fix-clang-cl-compilation.patch",
"0002-fix-msvc-arm64-compilation.patch",
"0003-fix-bsd-linking.patch"
]
```
Then, when Boost is downloaded, it will apply these patches in order to the source tree.
To learn how to make patches, see [Addendum: Making Patches](#addendum-making-patches).
## Pre-built CI Packages
The definition and usage of CI packages is subject to change in the very near future.
CI packages are, in essence, prebuilt binary distributions for libraries. They exist for a few reasons:
- Creating static libraries for system packages that normally lack them, e.g. Qt/SDL
- Reducing duplicated compilation effort on rarely-changing externals, e.g. SDL
- Creating debloated prebuilt packages specifically for your project to reduce binary size, e.g. FFmpeg
CPMUtil is specifically designed to work with a small subset of prebuilt CI packages; namely, those that follow the format of the [crueter-ci spec](https://github.com/crueter-ci/spec/blob/master/README.md).
To use them, you must add `ci: true` to your package definition. Alongside the common properties, CI packages define the following:
-`name`: The artifacts' name prefix (required), e.g. `openssl`
-`extension`: The artifacts' extension (default `tar.zst`)
-`disabled_platforms`: CPMUtil-supported platforms that are not built into this repository.
- This is subject to change.
**Note that `package` is subject to removal here.**
Example:
```json
"sdl2":{
"repo":"crueter-ci/SDL2",
"package":"SDL2",
"min_version":"2.26.4",
"ci":true,
"version":"2.32.10-a65111bd2d",
"artifact":"SDL2"
},
```
## Usage
Once you've defined your package in `cpmfile.json`, simply call `AddJsonPackage(<JSON key>)` and go from there! Specific instructions differ between individual packages, so you're on your own from here.
If you're only concerned with basic usage, you can stop reading. For more advanced use cases and package management, read these addenda.
## Addendum: Cache Storage
CPMUtil stores downloaded packages within `.cache/cpm` by default (see `CPM_SOURCE_CACHE`). Subdirectories stored within are lowercase representations of the `find_package` name for the package; for instance, a `vulkan-headers` definition with `package: "VulkanHeaders"` would be stored in `.cache/cpm/vulkanheaders`.
Within these subdirectories, additional directories are created for each individual version:
- A four-character shorthand of `sha`, if defined
- If `sha` is not defined, the fully qualified `version` is used
CI packages use `<platform>-<architecture>-<version>` unconditionally.
## Addendum: Making Patches
CPMUtil has a dedicated command for making patches. You're recommended to have Git and a command line editor installed, but CPMUtil is able to work without either. To do so, follow these steps, noting your package's JSON key:
- Clean-fetch your package: `tools/cpmutil.sh package reset <package>`
- Make any necessary modifications to the package source.
- You can access the package source directory via `tools/cpmutil.sh package dir <package>`.
- Create the patch: `tools/cpmutil.sh package patch <package>`
- Follow the on-screen prompts. If you have Git installed, an editor will be opened so you can type your commit message. If not, just type a one-line description.
And you're done! CPMUtil will automatically create and name the patch, and add it to the list of patches in the JSON definition.
## Addendum: Package Identification Lists
CPMUtil will create three lists of dependencies where `AddPackage` or similar was used. Each is in order of addition.
-`CPM_PACKAGE_NAMES`: The names of packages included by CPMUtil
-`CPM_PACKAGE_URLS`: The URLs to project/repo pages of packages
-`CPM_PACKAGE_SHAS`: Short version identifiers for each package
- If the package was included as a system package, `(system)` is appended thereafter
- Packages whose versions can't be deduced will be left as `unknown`.
For an example of how this might be implemented in an application, see Eden's implementation:
If you are packaging a project that uses CPMUtil, read this!
### Network Sandbox
For sandboxed environments (e.g. Gentoo, nixOS) you must install all dependencies to the system beforehand and set `-DCPMUTIL_FORCE_SYSTEM=ON`. If a dependency is missing, get creating!
Alternatively, if CPMUtil pulls in a package that has no suitable way to install or use a system version, download it separately and pass `-DPackageName_DIR=/path/to/downloaded/dir` (e.g. shaders)
### Unsandboxed
For others (AUR, MPR, etc). CPMUtil will handle everything for you, including if some of the project's dependencies are missing from your distribution's repositories. See [`eden-git`](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=eden-git) for an example.
## Addendum: Dependent Packages
Consider the following scenario: the Vulkan Headers and Vulkan Utility libraries are both pulled in by my project. In order for both to compile cleanly, their versions *must* match. However, a user may have the Vulkan Headers installed, but *not* the Vulkan Utility Libraries! This can cause a version mismatch where the Utility Libraries expect a much newer version of the Vulkan Headers than the user has installed.
To solve this, CPMUtil has an `AddDependentPackages` command. This takes a list of JSON package keys that *must* either ALL be installed to the system, or ALL be bundled.
- The user has both Vulkan Headers and Vulkan Utility Libraries installed to the system, and both are new enough.
- Configuration proceeds without issue.
- The user has neither installed, or has a too-old version of Vulkan Headers installed
- Configuration proceeds without issue.
- The user has a valid Vulkan Headers installed, but not Vulkan Utility Libraries.
- CPMUtil instructs the user to either force bundled Vulkan Headers, or install Vulkan Utility Libraries.
- The user has both installed, but Vulkan Headers are too old.
- CPMUtil instructs the user to install a valid version of Vulkan Headers, or force bundled Vulkan Utility Libraries.
## Addendum: Module Path Packages
Sometimes, a prebuilt CI package may be packed in such a way that it's meant to be used in the context of a system install (e.g. pkgconfig or CMakeConfig files). In this case, CPMUtil normally will be unable to configure the downloaded subdirectory. To solve this, you can use `AddJsonPackage`'s `MODULE_PATH` mode, which adds the downloaded source directory to the `CMAKE_MODULE_PATH`.
### Example: OpenSSL
Say an OpenSSL CI package is packed to contain its CMake config files rather than a root `CMakeLists.txt`; in this case, you would call:
```cmake
AddJsonPackage(NAMEopensslMODULE_PATH)
```
The `NAME` argument is also required, as the parsing is different from the standard single-argument function signature.
From here, calling `find_package(OpenSSL)` will use the bundled OpenSSL.
## Addendum: Adding Qt
If you'd like to use customized Qt builds, CPMUtil provides a convenience function that allows you to add Qt builds. This usage and setup is subject to change.
See [crueter-ci/Qt](https://github.com/crueter-ci/Qt) for an example of how one might build customized Qt. To add a Qt build to your project, use `AddQt(<repository> <version>)`, e.g.:
```cmake
AddQt(QDash-CI/Qt6.11.1)
```
Then, call `find_package(Qt6 ...)` and it will pull Qt from your downloaded source.
Use `AddDependentPackage` when you have multiple packages that are required to all be from the system, OR bundled. This is useful in cases where e.g. versions must absolutely match.
In each directory that utilizes `CPMUtil`, there must be a `cpmfile.json` that defines dependencies in a similar manner to the individual calls.
The cpmfile is an object of objects, with each sub-object being named according to the package's identifier, e.g. `openssl`, which can then be fetched with `AddJsonPackage(<identifier>)`. Options are designed to map closely to the argument names, and are always strings unless otherwise specified.
<!-- TOC -->
- [Options](#options)
- [Examples](#examples)
<!-- /TOC -->
## Options
-`package` -> `NAME` (`PACKAGE` for CI), defaults to the object key
-`repo` -> `REPO`
-`version` -> `VERSION`
-`ci` (bool)
If `ci` is `false`:
-`hash` -> `HASH`
-`hash_suffix` -> `HASH_SUFFIX`
-`sha` -> `SHA`
-`key` -> `KEY`
-`tag` -> `TAG`
- If the tag contains `%VERSION%`, that part will be replaced by the `git_version`, OR `version` if `git_version` is not specified
-`url` -> `URL`
-`artifact` -> `ARTIFACT`
- If the artifact contains `%VERSION%`, that part will be replaced by the `git_version`, OR `version` if `git_version` is not specified
- If the artifact contains `%TAG%`, that part will be replaced by the `tag` (with its replacement already done)
-`git_version` -> `GIT_VERSION`
-`git_host` -> `GIT_HOST`
-`source_subdir` -> `SOURCE_SUBDIR`
-`bundled` -> `BUNDLED_PACKAGE`
-`find_args` -> `FIND_PACKAGE_ARGUMENTS`
-`download_only` -> `DOWNLOAD_ONLY`
-`patches` -> `PATCHES` (array)
-`options` -> `OPTIONS` (array)
-`skip_updates`: Tells `check-updates.sh` to not check for new updates on this package.
Other arguments aren't currently supported. If you wish to add them, see the `AddJsonPackage` function in `CMakeModules/CPMUtil.cmake`.
If `ci` is `true`:
-`name` -> `NAME`, defaults to the object key
-`extension` -> `EXTENSION`, defaults to `tar.zst`
-`NAME` (required): The package name (must be the same as the `find_package` name if applicable)
-`VERSION`: The minimum version of this package that can be used on the system
-`GIT_VERSION`: The "version" found within git
-`URL`: The URL to fetch.
-`REPO`: The repo to use (`owner/repo`).
-`GIT_HOST`: The Git host to use
- Defaults to `github.com`. Do not include the protocol, as HTTPS is enforced.
-`TAG`: The tag to fetch, if applicable.
-`ARTIFACT`: The name of the artifact, if applicable.
-`SHA`: Commit sha to fetch, if applicable.
-`BRANCH`: Branch to fetch, if applicable.
The following configurations are supported, in descending order of precedence:
-`URL`: Bare URL download, useful for custom artifacts
- If this is set, `GIT_URL` or `REPO` should be set to allow the dependency viewer to link to the project's Git repository.
- If this is NOT set, `REPO` must be defined.
-`REPO + TAG + ARTIFACT`: GitHub release artifact
- The final download URL will be `https://github.com/${REPO}/releases/download/${TAG}/${ARTIFACT}`
- Useful for prebuilt libraries and prefetched archives
-`REPO + TAG`: GitHub tag archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/tags/${TAG}.tar.gz`
- Useful for pinning to a specific tag, better for build identification
-`REPO + SHA`: GitHub commit archive
- The final download URL will be `https://github.com/${REPO}/archive/${SHA}.zip`
- Useful for pinning to a specific commit
-`REPO + BRANCH`: GitHub branch archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/heads/${BRANCH}.zip`
- Generally not recommended unless the branch is frozen
-`REPO`: GitHub master archive
- The final download URL will be `https://github.com/${REPO}/archive/refs/heads/master.zip`
- Generally not recommended unless the project is dead
## Hashing
Hashing is used for verifying downloads. It's highly recommended to use these.
-`HASH_ALGO` (default `SHA512`): Hash algorithm to use
Hashing strategies, descending order of precedence:
-`HASH`: Bare hash verification, useful for static downloads e.g. commit archives
-`HASH_SUFFIX`: Download the hash as `${DOWNLOAD_URL}.${HASH_SUFFIX}`
- The downloaded hash *must* match the hash algorithm and contain nothing but the hash; no filenames or extra content.
-`HASH_URL`: Download the hash from a separate URL
## Other Options
-`KEY`: Custom cache key to use (stored as `.cache/cpm/${packagename_lower}/${key}`)
- Default is based on, in descending order of precedence:
- First 4 characters of the sha
-`GIT_VERSION`
- Tag
-`VERSION`
- Otherwise, CPM defaults will be used. This is not recommended as it doesn't produce reproducible caches
-`DOWNLOAD_ONLY`: Whether or not to configure the downloaded package via CMake
- Useful to turn `OFF` if the project doesn't use CMake
-`SOURCE_SUBDIR`: Subdirectory of the project containing a CMakeLists.txt file
-`FIND_PACKAGE_ARGUMENTS`: Arguments to pass to the `find_package` call
-`BUNDLED_PACKAGE`: Set to `ON` to default to the bundled package
-`FORCE_BUNDLED_PACKAGE`: Set to `ON` to force the usage of the bundled package, regardless of CPMUTIL_FORCE_SYSTEM or `<package>_FORCE_SYSTEM`
-`OPTIONS`: Options to pass to the configuration of the package
-`PATCHES`: Patches to apply to the package, stored in `.patch/${packagename_lower}/0001-patch-name.patch` and so on
- Other arguments can be passed to CPM as well
## Extra Variables
For each added package, users may additionally force usage of the system/bundled package.
-`${package}_DIR`: Path to a separately-downloaded copy of the package. Note that versioning is not checked!
-`${package}_FORCE_SYSTEM`: Require the package to be installed on the system
-`${package}_FORCE_BUNDLED`: Force the package to be fetched and use the bundled version
## System/Bundled Packages
Descending order of precedence:
- If `${package}_FORCE_SYSTEM` is true, requires the package to be on the system
- If `${package}_FORCE_BUNDLED` is true, forcefully uses the bundled package
- If `CPMUTIL_FORCE_SYSTEM` is true, requires the package to be on the system
- If `CPMUTIL_FORCE_BUNDLED` is true, forcefully uses the bundled package
- If the `BUNDLED_PACKAGE` argument is true, forcefully uses the bundled package
- Otherwise, CPM will search for the package first, and if not found, will use the bundled package
## Identification
All dependencies must be identifiable in some way for usage in the dependency viewer. Lists are provided in descending order of precedence.
URLs:
-`GIT_URL`
-`REPO` as a Git repository
- You may optionally specify `GIT_HOST` to use a custom host, e.g. `GIT_HOST git.crueter.xyz`. Note that the git host MUST be GitHub-like in its artifact/archive downloads, e.g. Forgejo
- If `GIT_HOST` is unspecified, defaults to `github.com`
-`URL`
Versions (bundled):
-`SHA`
-`GIT_VERSION`
-`VERSION`
-`TAG`
- "unknown"
If the package is a system package, AddPackage will attempt to determine the package version and append `(system)` to the identifier. Otherwise, it will be marked as `unknown (system)`
Simply call `AddQt(<Qt Version>)` before any Qt `find_package` calls and everything will be set up for you. On Linux, the bundled Qt library is built as a shared library, and provided you have OpenSSL and X11, everything should just work.
On Windows, MinGW, and MacOS, Qt is bundled as a static library. No further action is needed, as the provided libraries automatically integrate the Windows/Cocoa plugins, alongside the corresponding Multimedia and Network plugins.
## Modules
The following modules are bundled into these Qt builds:
- Base (Gui, Core, Widgets, Network)
- Multimedia
- Declarative (Quick, QML)
- Linux: Wayland client
Each platform has the corresponding QPA built in and set as the default as well. This means you don't need to add `Q_IMPORT_PLUGIN`!
## Example
See an example in the [`tests/qt`](https://git.crueter.xyz/CMake/CPMUtil/src/branch/master/tests/qt/CMakeLists.txt) directory.
## Versions
The following versions have available builds:
- 6.9.3
See [`crueter-ci/Qt`](https://github.com/crueter-ci/Qt) for an updated list at any time.
CPMUtil is a wrapper around CPM that aims to reduce boilerplate and add useful utility functions to make dependency management a piece of cake.
Global Options:
-`CPMUTIL_FORCE_SYSTEM` (default `OFF`): Require all CPM dependencies to use system packages. NOT RECOMMENDED!
- You may optionally override this (section)
-`CPMUTIL_FORCE_BUNDLED` (default `ON` on MSVC and Android, `OFF` elsewhere): Require all CPM dependencies to use bundled packages.
You are highly encouraged to read AddPackage first, even if you plan to only interact with CPMUtil via `AddJsonPackage`.
- [AddPackage](#addpackage)
- [AddCIPackage](#addcipackage)
- [AddJsonPackage](#addjsonpackage)
- [AddQt](#addqt)
- [Lists](#lists)
- [For Packagers](#for-packagers)
- [Network Sandbox](#network-sandbox)
- [Unsandboxed](#unsandboxed)
## AddPackage
The core of CPMUtil is the [`AddPackage`](./AddPackage.md) function. [`AddPackage`](./AddPackage.md) itself is fully CMake-based, and largely serves as an interface between CPM and the rest of CPMUtil.
## AddCIPackage
[`AddCIPackage`](./AddCIPackage.md) adds a package that follows [crueter's CI repository spec](https://github.com/crueter-ci).
## AddJsonPackage
[`AddJsonPackage`](./AddJsonPackage.md) is the recommended method of usage for CPMUtil.
## AddDependentPackage
[`AddDependentPackage`](./AddDependentPackage.md) allows you to add multiple packages such that all of them must be from the system OR bundled.
## AddQt
[`AddQt`](./AddQt.md) adds a specific version of Qt to your project.
## Lists
CPMUtil will create three lists of dependencies where `AddPackage` or similar was used. Each is in order of addition.
-`CPM_PACKAGE_NAMES`: The names of packages included by CPMUtil
-`CPM_PACKAGE_URLS`: The URLs to project/repo pages of packages
-`CPM_PACKAGE_SHAS`: Short version identifiers for each package
- If the package was included as a system package, `(system)` is appended thereafter
- Packages whose versions can't be deduced will be left as `unknown`.
For an example of how this might be implemented in an application, see Eden's implementation:
If you are packaging a project that uses CPMUtil, read this!
### Network Sandbox
For sandboxed environments (e.g. Gentoo, nixOS) you must install all dependencies to the system beforehand and set `-DCPMUTIL_FORCE_SYSTEM=ON`. If a dependency is missing, get creating!
Alternatively, if CPMUtil pulls in a package that has no suitable way to install or use a system version, download it separately and pass `-DPackageName_DIR=/path/to/downloaded/dir` (e.g. shaders)
### Unsandboxed
For others (AUR, MPR, etc). CPMUtil will handle everything for you, including if some of the project's dependencies are missing from your distribution's repositories. That is pretty much half the reason I created this behemoth, after all.
@@ -31,21 +32,21 @@ If you're having issues with building, always consult that ebuild.
macOS is largely untested. Expect crashes, significant Vulkan issues, and other fun stuff.
## Solaris
## OpenIndiana
Always consult [the OpenIndiana package list](https://pkg.openindiana.org/hipster/en/index.shtml) to cross-verify availability.
Run the usual update + install of essential toolings: `sudo pkg update && sudo pkg install git cmake`.
- **gcc**: `sudo pkg install developer/gcc-14`.
- **clang**: Version 20 is broken, use `sudo pkg install developer/clang-19`.
- **gcc**: Install either `developer/gcc-14`.
- **clang**: Version 20 is broken, install `developer/clang-19`.
Qt Widgets appears to be broken. For now, add `-DENABLE_QT=OFF` to your configure command. In the meantime, a Qt Quick frontend is in the works--check back later!
This is needed for some dependencies that call cc directly (tz):
```sh
echo'#!/bin/sh' >cc
echo'#!/bin/sh -e' >cc
echo'gcc $@' >>cc
chmod +x cc
exportPATH="$PATH:$PWD"
@@ -64,9 +65,33 @@ export LIBGL_ALWAYS_SOFTWARE=1
```
- Modify the generated ffmpeg.make (in build dir) if using multiple threads (base system `make` doesn't use `-j4`, so change for `gmake`).
- If using OpenIndiana, due to a bug in SDL2's CMake configuration, audio driver defaults to SunOS `<sys/audioio.h>`, which does not exist on OpenIndiana. Using external or bundled SDL2 may solve this.
- System OpenSSL generally does not work. Instead, use `-DYUZU_USE_BUNDLED_OPENSSL=ON` to use a bundled static OpenSSL, or build a system dependency from source.
## OmniOS
Install `developer/gcc14` on OmniOS using pkgsrc.
Since so many dependencies are missing on `OmniOS`, you may wish to use `-DCPMUTIL_FORCE_BUNDLED=ON`
For OmniOS you are required to build glslang yourself:
It may be tempting to specify `-t glslang`, but this will cause installation to fail. So don't.
Using `--parallel` on CMake incorrectly passes `dmake ... -jn` instead of `dmake ... -j n`, this is a bug with OmniOS's CMake, and as such it's recommended to not use this option until it's fixed.
You may also need to install `gmake` in order to properly build FFmpeg, this is provided by the `build-essential` package.
If it wasn't obvious already, you require a X11 server to properly run the emulator within OmniOS, [this guide](https://web.archive.org/web/20260424200928/https://geekblood.wordpress.com/2017/10/26/installing-x11-and-a-desktop-environment-on-omnios/) is a great starting point for that, the links to pkgsrc are outdated so follow [this exemplar](https://pkgsrc.smartos.org/install-on-illumos/) as well:
## HaikuOS
It's recommended to do a `pkgman full-sync` before installing. See [HaikuOS: Installing applications](https://www.haiku-os.org/guides/daily-tasks/install-applications/). Sometimes the process may be interrupted by an error like "Interrupted syscall". Simply firing the command again fixes the issue. By default `g++` is included on the default installation.
Gentoo's cross-compilation setup is relatively easy, provided you're already familiar with portage. A [cross toolchain file](../CMakeModules/toolchains/GentooCross.cmake) is provided. Throughout this section, replace `aarch64` with whatever target architecture you desire.
### Crossdev
First, emerge crossdev via `sudo emerge -a sys-devel/crossdev`.
Now, set up the environment depending on the target architecture; e.g.
```sh
sudo crossdev aarch64
```
### QEMU
If you don't have a host Gentoo system of your target architecture, you should install a QEMU user setup for testing. To do so, enable the relevant USE flags for `app-emulation/qemu`:
To use cross-emerged shared libraries, you will also need to tell qemu where the sysroot is. You can do this with an alias:
```sh
alias qemu-aarch64="qemu-aarch64 -L /usr/aarch64-unknown-linux-gnu"
```
### Dependencies
Dependencies are the same [as normal Gentoo](./Deps.md#Commands); simply replace the `emerge` command with `emerge-<target>-unknown-linux-gnu` (e.g. `emerge-aarch64-unknown-linux-gnu`). However, there are a few caveats:
#### Enabling GURU
Since Crossdev sysroots are effectively isolated from the system w.r.t Portage, you must manually enable GURU in your sysroot. Run the following as root:
Crossdev is not perfect, and you may face some challenges with package that are not properly keyworded or have issues on specific architectures. These behaviors are, unfortunately, not well documented, and certain build systems such as Meson--and certain troublesome packages like GTK--are generally unfriendly towards cross-compilation.
Thus, it may be desirable to emerge a minimal set of dependencies and allow Eden's build system to handle the rest for you. At a minimum, you *only* need standard system libraries (Crossdev does this for you) and Qt:
From here, CPMUtil will take care of everything else. For extra insurance, you may want to set `-DCPMUTIL_FORCE_BUNDLED=ON` in your configure command.
### Building
From here, building is relatively standard. The [cross toolchain file](../CMakeModules/toolchains/GentooCross.cmake) contains a few additional configurations, but generally all you need to do is set `CROSS_TARGET` and `CMAKE_TOOLCHAIN_FILE`. Disabling OpenGL is strongly recommended as well.
@@ -9,6 +9,7 @@ When reporting issues or finding bugs, we often need backtraces, debug logs, or
If your bug is related to a graphical issue--e.g. mismatched colors, vertex explosions, flickering, etc.--then you are required to include graphical debugging logs in your issue reports.
Graphics Debugging is found in General -> Debug on desktop, and Advanced Settings -> Debug on Android. Android users are all set; however, desktop users may need to install the Vulkan Validation Layers:
- Windows: Install the [Vulkan SDK](https://vulkan.lunarg.com/sdk/home)
- Linux, BSD, etc: Install `vulkan-validation-layers`, `vulkan-layers`, or similar from your package manager. It should be located in e.g. `/usr/lib64/libVkLayer_khronos_validation.so`
@@ -30,15 +31,16 @@ Ignoring SIGSEGV when debugging in host:
### gdb
You must have GDB installed for aarch64 to debug the target. Install it through your package manager, e.g.:
Run `./build/bin/eden-cli -c <path to your config file (see logs where you run eden normally to see where it is)> -d -g <path to game>`, or `Enable GDB Stub` at General > Debug, then hook up an aarch64-gdb:
-`target remote localhost:6543`
Type `c` (for continue) and then if it crashes just do a `bt` (backtrace) and `layout asm`
@@ -67,28 +69,6 @@ Expressions can be `variable_names` or `1234` (numbers) or `*var` (dereference o
For more information type `info gdb` and read [the man page](https://man7.org/linux/man-pages/man1/gdb.1.html).
## Simple checklist for debugging black screens using Renderdoc
# RenderDoc (Graphic Debugging Tool)
Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it [here](https://renderdoc.org).
Before using renderdoc to diagnose issues, it is always good to make sure there are no validation errors. Any errors means the behavior of the application is undefined. That said, renderdoc can help debug validation errors if you do have them.
When debugging a black screen, there are many ways the application could have setup Vulkan wrong.
Here is a short checklist of items to look at to make sure are appropriate:
* Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
* Vertex buffers are bound
* vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
* Any bound push constants and descriptors have the right data - including:
* Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
* Pipeline state is correct
* viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
* Fill mode matches expected - usually solid
* Culling mode makes sense - commonly back or none
* The winding direction is correct - typically CCW (counter clockwise)
* Scissor region is correct - usually same as viewport's x,y,width, &height
* Blend state is correct
* Depth state is correct - typically enabled with Function set to Less than or Equal
* Swapchain images are bound when rendering to the swapchain
* Image being rendered to is the same as the one being presented when rendering to the swapchain
Alternatively, a [RenderDoc Extension](https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw) ([Archive](https://web.archive.org/web/20250000000000*/https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw)) exists which automates doing a lot of these manual steps.
Guidelines for graphical debugging using RenderDoc: **[RenderDoc usage](./RenderDoc.md)**
* **[Python3](https://www.python.org/downloads/)** 3.10+ - necessary to download external repositories
@@ -35,6 +35,11 @@ If you are on desktop and plan to use the Qt frontend, you *must* install Qt 6,
* For help setting up Qt Creator, run `./install.sh -h qtcreator`
* If you're using clang-cl and want to still use MSVC
* Check the option to add "C++ clang compiler for Windows" on Visual Studio installer and uncheck "x64/x86 build tool for MSVC" while selecting "C++ desktop developement tools" and change Visual Studio to 2026, from 2022.
* At qt creator section generator tab change Visual Studio 17 2022 to 2026.
* Finally, to use clang-cl: `cmake -S . -B build -G "Visual Studio 17 2026" -T ClangCL`
If you are on **Windows** and building with **MSVC** or **clang-cl**, you may go [back home](Build.md) and continue.
## Externals
@@ -42,7 +47,7 @@ If you are on **Windows** and building with **MSVC** or **clang-cl**, you may go
The following are handled by Eden's externals:
* [FFmpeg](https://ffmpeg.org/) (should use `-DYUZU_USE_EXTERNAL_FFMPEG=ON`)
* [SDL2](https://www.libsdl.org/download-2.0.php) 2.0.18+ (should use `-DYUZU_USE_EXTERNAL_SDL2=ON` OR`-DYUZU_USE_BUNDLED_SDL2=ON` to reduce compile time)
* [SDL3](https://www.libsdl.org/download-2.0.php) 3.2.10+ (Use`-DYUZU_USE_BUNDLED_SDL2=ON` to reduce compile time)
All other dependencies will be downloaded and built by [CPM](https://github.com/cpm-cmake/CPM.cmake/) if `YUZU_USE_CPM` is on, but will always use system dependencies if available (UNIX-like only):
All commits must have proper license header accreditation.
You can easily add all necessary license headers by running:
```sh
git fetch origin master:master
.ci/license-header.sh -u -c
@@ -11,6 +13,7 @@ git push
```
Alternatively, you may omit `-c` and do an amend commit:
```sh
git fetch origin master:master
.ci/license-header.sh
@@ -22,8 +25,10 @@ If the work is licensed/vendored from other people or projects, you may omit the
For more information on the license header script, run `.ci/license-header.sh -h`.
## Pull Requests
Pull requests are only to be merged by core developers when properly tested and discussions conclude on Discord or other communication channels. Labels are recommended but not required. However, all PRs MUST be namespaced and optionally typed:
```
```txt
[cmake] refactor: CPM over submodules
[desktop] feat: implement firmware install from ZIP
[hle] stub fw20 functions
@@ -34,7 +39,7 @@ Pull requests are only to be merged by core developers when properly tested and
- The level of namespacing is generally left to the committer's choice.
- However, we never recommend going more than two levels *except* in `hle`, in which case you may go as many as four levels depending on the specificity of your changes.
- Ocassionally, up to two additional namespaces may be provided for more clarity.
* Changes that affect the entire project (sans CMake changes) should be namespaced as `meta`.
- Changes that affect the entire project (sans CMake changes) should be namespaced as `meta`.
- Maintainers are permitted to change namespaces at will.
- Commits within PRs are not required to be namespaced, but it is highly recommended.
@@ -50,6 +55,7 @@ When adding new settings, use `tr("Setting:")` if the setting is meant to be a f
- Try to not write "slow/fast" options unless it clearly degrades/increases performance for a given case, as most options may modify behaviour that result in different metrics accross different systems. If for example the option is an "accuracy" option, writing "High" is sufficient to imply "Slow". No need to write "High (Slow)".
Some examples:
- "[...] negatively affecting image quality", "[...] degrading image quality": Same wording but with less filler.
- "[...] this may cause some glitches or crashes in some games", "[...] this may cause soft-crashes": Crashes implies there may be glitches (as crashes are technically a form of a fatal glitch). The entire sentence is structured as "may cause [...] on some games", which is redundant, because "may cause [...] in games" has the same semantic meaning ("may" is a chance that it will occur on "some" given set).
- "FIFO Relaxed is similar to FIFO [...]", "FIFO Relaxed [...]": The name already implies similarity.
@@ -57,13 +63,16 @@ Some examples:
- "[...] it can [...] in some cases", "[...] it can [...]": Implied probability.
Before adding a new setting, consider:
- Does the piece of code that the setting pertains to, make a significant difference if it's on/off?
- Can it be auto-detected?
# IDE setup
## VSCode
Copy this to `.vscode/settings.json`, get CMake tools and it should be ready to build:
```json
{
"editor.tabSize":4,
@@ -83,6 +92,7 @@ You may additionally need the `Qt Extension Pack` extension if building Qt.
# Build speedup
If you have an HDD, use ramdisk (build in RAM), approximatedly you need 4GB for a full build with debug symbols:
```sh
mkdir /tmp/ramdisk
chmod 777 /tmp/ramdisk
@@ -96,128 +106,11 @@ umount /tmp/ramdisk
# Assets and large files
A general rule of thumb, before uploading files:
- PNG files: Use [optipng](https://web.archive.org/web/20240325055059/https://optipng.sourceforge.net/).
- SVG files: Use [svgo](https://github.com/svg/svgo).
May not be used but worth mentioning nonethless:
- OGG files: Use [OptiVorbis](https://github.com/OptiVorbis/OptiVorbis).
- Video files: Use ffmpeg, preferably re-encode as AV1.
# Bisecting older commits
Since going into the past can be tricky (especially due to the dependencies from the project being lost thru time). This should "restore" the URLs for the respective submodules.
If having issues with older artifacts, then run `rm -r externals/dynarmic/build externals/dynarmic/externals externals/nx_tzdb/tzdb_to_nx/externals externals/sirit/externals`.
Configuring CMake with `-DSIRIT_USE_SYSTEM_SPIRV_HEADERS=1 -DCMAKE_CXX_FLAGS="-Wno-error" -DCMAKE_C_FLAGS="-Wno-error -Wno-array-parameter -Wno-stringop-overflow"` is also recommended.
In brief, the HOS kernel is a microkernel, all services and programs run in userspace, the primary way to do communication between these is via `HIPC` (not covered here); otherwise most of the primitives reside in the forms of syscalls invoked via `svc #imm`. The kernel supports both 32-bit and 64-bit programs, and has the capacity to use 32, 36 and 39 bits of address space for spawned processes. Most of the networking stack is based off FreeBSD's network stack.
The emulator implements the majority of the syscalls pertaining to the HOS kernel itself. When we talk about the HOS Kernel (in the context of the emulator) we are strictly speaking about the mechanisms from which syscalls are handled (and it's subsequent side effects, such as the page table book-keeping). The emulator at it's current state is unable to load a custom low-level kernel and do supervisor-level emulation.
Most programs in NX eventually invoke an `svc`, which, depending on it's immediate value, will go on to be dispatched into one of the specific syscall handlers.
These can be seen in [svc.cpp](/src/core/hle/kernel/svc.cpp). All of these correspond to syscalls which userspace programs may perform.
In turn, these syscalls create the mechanisms that allows programs to use CMIF/TIPC as their primary IPC form to contact other services/processes running on the system, the details of which will not be covered here, but you can consult the relevant [SwitchBrew article: 'HIPC'](https://switchbrew.org/wiki/HIPC).
From the point of view of the programs, no special devices (such as PCIE, Realtek drivers, Bluetooth or USB) has to be handled by the emulator; this is because most of the fun occurs in specialized services such as `usb:u` or `pcie` services. Which aren't emulated (yet).
Due to the nature of syscalls, many of them interact with memory. The emulated kernel has an internal tree-like structure, borrowed from FreeBSD's intrusive red-black tree; this is used to track and find mappings added or removed. Thus most of the process space is emulated in this way.
The kernel keeps it's own separate pagetable, in a traditional sense, each process has it's own pagetable, this is true for HOS as well.
Every process keeps it's own tracking of the following structures:
- Name (13 characters)
- 64-bit ID
- A handle table
- Exclusive monitor
- Threads
- Held locks
- Thread local pages
- A page table for each process
The emulator willingly restricts itself to only use 4 threads (to emulate 4 cores), this is because most existing applications do not benefit greatly from the added core count, and in fact can be detrimental due to extra contention. This translates equitatively to about 4 `ArmInterface` slots for each process, these are then redirected to whatever is the last `pc` of the last thread running on the core is meant to be; proceed to run it, then when returning (due to halt or interruption), proceed to reschedule the thread.
The scheduler as-is isn't 100% faithful to the original (for example the original is cooperative and not preemptive), and has great timing variance (especially due to the fact the emulator can run in systems with wildly different timings).
-`YUZU_USE_BUNDLED_OPENSSL` (ON for MSVC, Android, Solaris, and OpenBSD) Download bundled OpenSSL build
-`YUZU_USE_EXTERNAL_SDL2` (OFF) Compiles SDL2 from source
-`YUZU_USE_BUNDLED_SDL2` (ON for MSVC) Download a prebuilt SDL2
-`YUZU_USE_BUNDLED_SDL3` (ON for MSVC) Download a prebuilt SDL3
### Miscellaneous
@@ -44,6 +43,9 @@ These options control dependencies.
- UNIX may be better off appending `-flto=thin` to compiler args
-`USE_FASTER_LINKER` (OFF) Check if a faster linker is available
- Not recommended outside of Linux
-`YUZU_INSTALL_UDEV_RULES` (OFF) Install udev rules to enable hidraw access
- Needed for gyroscopes
- Only available on Linux
### Flavors
@@ -60,7 +62,7 @@ These options control executables and build flavors.
**Desktop only**:
-`YUZU_CMD` (ON) Compile the SDL2 frontend (eden-cli)
-`YUZU_CMD` (ON) Compile the SDL-based frontend (eden-cli)
-`YUZU_ROOM` (OFF) Compile dedicated room functionality into the main executable
-`YUZU_ROOM_STANDALONE` (OFF) Compile a separate executable for room functionality
-`YUZU_STATIC_ROOM` (OFF) Compile the room executable *only* as a static, portable executable
@@ -96,5 +98,6 @@ The following options were a part of Eden at one point, but have since been reti
-`ENABLE_SDL2` - While technically possible to *not* use SDL2 on desktop, this is **NOT** a supported configuration under any means, and adding this matrix to our build system was not worth the effort.
-`YUZU_USE_CPM` - This option once had a purpose, but that purpose has long since passed us by. *All* builds use CPMUtil to manage dependencies now.
- If you want to *force* the usage of system dependencies, use `-DCPMUTIL_FORCE_SYSTEM=ON`.
-`YUZU_USE_EXTERNAL_SDL` - This is now handled automatically. It was included even after CPM for purposes that have not applied for a very long time.
See `src/dynarmic/CMakeLists.txt` for additional options--usually, these don't need changed
Are you just a casual user? Take a look at our [User Handbook](./user) then!
If you want to register/signup as a contributor, take a gander at the [signup guide](./SIGNUP.md).
This contains documentation created by developers. This contains build instructions, guidelines, instructions/layouts for [cool stuff we made](./CPMUtil), and more.
Renderdoc is a free, cross platform, multi-graphics API debugger. It is an invaluable tool for diagnosing issues with graphics applications, and includes support for Vulkan. Get it at [renderdoc.org](https://renderdoc.org).
RenderDoc can capture Eden's Vulkan output when its Vulkan layer is loaded before Eden creates the Vulkan device. Before using renderdoc to diagnose issues, it is always good to make sure there are no validation errors. Any errors means the behavior of the application is undefined. That said, renderdoc can help debug validation errors if you do have them.
## Usage on Windows
You can either use RenderDoc UI to launch eden, or you can make eden attach it internally:
On Windows PowerShell:
```powershell
$env:ENABLE_VULKAN_RENDERDOC_CAPTURE='1'
.\eden.exe
```
When RenderDoc is attached, Eden logs the default Windows capture folder:
```text
%LOCALAPPDATA%\Temp\RenderDoc
```
Press RenderDoc's capture hotkey, usually `F12`, to capture a frame. To stop using RenderDoc, close Eden and launch it again without `ENABLE_VULKAN_RENDERDOC_CAPTURE`.
## Eden Hotkey
Eden also has a separate `Toggle Renderdoc Capture` hotkey behind the debug setting `renderdoc_hotkey`.
That hotkey does not load or unload RenderDoc. It only toggles Eden's own manual capture through RenderDoc's API:
- first press: starts a capture
- second press: ends that capture
## Simple checklist for debugging black screens using Renderdoc
When debugging a black screen, there are many ways the application could have setup Vulkan wrong.
Here is a short checklist of items to look at to make sure are appropriate:
- Draw call counts are correct (aka not zero, or if rendering many triangles, not 3)
- Vertex buffers are bound
- vertex attributes are correct - Make sure the size & offset of each attribute matches what should it should be
- Any bound push constants and descriptors have the right data - including:
- Matrices have correct values - double check the model, view, & projection matrices are uploaded correctly
- Pipeline state is correct
- viewport range is correct - x,y are 0,0; width & height are screen dimensions, minDepth is 0, maxDepth is 1, NDCDepthRange is 0,1
- Fill mode matches expected - usually solid
- Culling mode makes sense - commonly back or none
- The winding direction is correct - typically CCW (counter clockwise)
- Scissor region is correct - usually same as viewport's x,y,width, &height
- Blend state is correct
- Depth state is correct - typically enabled with Function set to Less than or Equal
- Swapchain images are bound when rendering to the swapchain
- Image being rendered to is the same as the one being presented when rendering to the swapchain
Alternatively, a [RenderDoc Extension](https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw) ([Archive](https://web.archive.org/web/20250000000000*/https://github.com/baldurk/renderdoc-contrib/tree/main/baldurk/whereismydraw)) exists which automates doing a lot of these manual steps.
> This guide is intended for developers ONLY. If you're looking for configuring the emulator itself, please read **[the user handbook](./user/README.md)**.
Settings on the emulator are very important, toggles and such can be used to guard and/or add branches to paths where some games may crash while others won't, and viceversa.
However, this process can be tedious for those unfamiliar; this document serves as a outline/documentation for the settings subsystem.
<stringname="your_setting_name_description">Detailed description of what this setting does. Explain any caveats, requirements, or warnings here.</string>
```
---
### Step 4 - Use Your Toggle!
Now the UI part is done find a place in the code for the toggle,
If you wish to do something only when the toggle is disabled,
Use `if (!your_value) {` instead of `if (your_value) {`.
---
### Best Practices
* Naming - Use clear, descriptive names. Something for both the devs and the users.
* Defaults - Choose safe default values (usually false for new features).
* Documentation - Write clear descriptions explaining when and why to use the setting.
* Categories - Put settings in the appropriate category.
* Order - Place related settings near each other.
* Testing - Always test on both PC and Android before committing when possible.
Thank you for reading, I hope this guide helped you making your toggle!
## Adding Debug Knobs
Debug Knobs is a 16-bit integer setting (`debug_knobs`) in the Eden Emulator that serves as a bitmask for gating various testing and debugging features. This allows developers and advanced users to enable or disable specific debug behaviors without requiring deploying of complete but temporary toggles.
The setting ranges from 0 to 65535 (0x0000 to 0xFFFF), where each bit represents a different debug feature flag.
---
### Advantages
The main advantage is to avoid deploying new disposable toggles (those made only for testing stage, and are disposed once new feature gets good to merge). This empowers devs to be free of all frontend burocracy and hassle of new toggles.
Common advantages recap:
* **Fine-Grained Control**: Enable or disable up to 16 individual debug features independently using bit manipulation on a single build
* **Runtime Configuration**: Change debug behavior at runtime the same way as new toggles would do
* **Safe incremental development**: New debug features can be added while impact can be isolated from previous deployments
### Usage
#### Accessing Debug Knobs (dev side)
Use the `Settings::getDebugKnobAt(u8 i)` function to check if a specific bit is set:
boolfeature_enabled=Settings.getDebugKnobAt(x);//x as integer from 0 to 15
```
The function returns `true` if the specified bit (0-15) is set in the `debug_knobs` value, `false` otherwise.
#### Setting Debug Knobs (user side)
Developers must inform which knobs are tied to each functionality to be tested.
The debug knobs value can be set through:
1.**Desktop UI**: In the Debug configuration tab, there's a spinbox for "Debug knobs" (0-65535)
2.**Android UI**: Available as an integer setting in the Debug section
3.**Configuration Files**: Set the `debug_knobs` value in the emulator's configuration
#### Bit Manipulation Examples
To enable specific features, calculate the decimal value by setting the appropriate bits:
* **Enable only bit 0**: Value = 1 (2^0)
* **Enable only bit 1**: Value = 2 (2^1)
* **Enable bits 0 and 1**: Value = 3 (2^0 + 2^1)
* **Enable bit 15**: Value = 32768 (2^15)
### Terminology and user communication
There are two main confusions when talking about knobs:
#### Whether it's zero-based or one-based
Sometimes when an user reports: knobs 1 and 2 gets better performance, dev may get confuse whether he means the knobs 1 and 2 literally, or the 1st and 2nd knobs (knobs 0 and 1).
Debug knobs are **zero-based**, which means:
* The first knob is the knob(0) (or knob0 henceforth), and the last one is the 15 (knob15, likewise)
* You can talk: "knob0 is enabled/disabled", "In this video i was using only knobs 0 and 2", etc.
#### Whether one is talking about the knob itself or about the entire parameter value (which represents all knobs)
Sometimes when an user reports: knob 3 results, it's unclear whether he's referring to knob setting with value 3 (which means both knob 0 and 1 are enabled), or to knob(3) specifically.
Whenever you're instructing tests or reporting results, be precise about whether one you're talking to avoid confusion:
#### Setting based terminology
ALWAYS use the word in PLURAL (knobs), without mentioning which one, to refer to the setting, aka multiple knobs at once:
Examples:
- **knobs=0**: no knobs enabled
- **knobs=1**: knob0 enabled, others disabled
- **knobs=2**: knob1 enabled, others disabled
- **knobs=3**: knobs 0 and 1 enabled, others disabled
...
#### Knob based terminology
Use the word in SINGULAR (knob), or in plural but referring which ones, when meaning multiple knobs at once:
Examples:
- **knob0**: knob 0 enabled, others disabled
- **knob1**: knob 1 enabled, others disabled
- **knobs 0 and 1**: knobs 0 and 1 enabled, others disabled
...
### Examples
#### Example 1: Conditional Debug Logging
```cpp
voidSomeFunction(){
if(Settings::getDebugKnobAt(0)){
LOG_DEBUG(Common,"Debug feature 0 is enabled");
// Additional debug code here
}
if(Settings::getDebugKnobAt(1)){
LOG_DEBUG(Common,"Debug feature 1 is enabled");
// Different debug behavior
}
}
```
#### Example 2: Performance Tuning
```cpp
boolUseOptimizedPath(){
// Skip optimization if debug bit 2 is set for testing
Bisecting and debugging older versions of Eden can be difficult, as many of our submodules have been deleted or removed. However, work has been done to make this process as simple as possible for users.
## Script
Copy the following script and store it in `fix.sh`:
These are mostly "suggestions", if you feel like your code is readable, comprehensible to others; and most importantly doesn't result in unreadable spaghetti you're fine to go.
These are **not** stylistic guidelines, they're, for the most part, suggestions on how to architecture new systems or improve upon the existing codebase.
But for new developers you may find that following these guidelines will make everything x10 easier.
# Foreword
## Naming conventions
Don't try to micro-optimize out of the get go, while yes, most of the code is pretty, subpar, most of these are aftertoughts and details that can be glossed over **generally**.
Simply put, types/classes are named as `PascalCase`, same for methods and functions like `AddElement`. Variables are named `like_this_snake_case` and constants are `IN_SCREAMING_CASE`.
Architectural issues are more important, for example an API returning a `std::string` is not as efficient as one that operates on `std::string_view` directly (cost of constructing an `std::string` w/o small-string optimization and all of that).
Except for Qt MOC where `functionName` is preferred.
Regardless of the details, try to keep things simple. As a general rule of thumb.
Template typenames prefer short names like `T`, `I`, `U`, if a longer name is required either `Iterator` or `perform_action` are fine as well. Do not use names like `SS` as systems like solaris define it for registers, in general do not use any of the following for short names:
# C++ guidelines
-`SS`, `DS`, `GS`, `FS`: Segment registers, defined by Solaris `<ucontext.h>`
-`EAX`, `EBX`, `ECX`, `EDX`, `ESI`, `EDI`, `ESP`, `EBP`, `EIP`: Registers, defined by Solaris.
-`X`: Defined by some utility headers, avoid.
-`_`: Defined by gettext, avoid.
-`N`, `M`, `S`: Preferably don't use this for types, use it for numeric constants.
-`TR`: Used by some weird `<ucontext.h>` whom define the Task Register as a logical register to provide to the user... (Need to remember which OS in specific).
Everyone has their own way of viewing good/bad C++ practices, my general outline:
Macros must always be in `SCREAMING_CASE`. Do not use short letter macros as systems like Solaris will conflict with them; a good rule of thumb is >5 characters per macro - i.e `THIS_MACRO_IS_GOOD`, `AND_ALSO_THIS_ONE`.
- At your disposal you may use `boost::container::static_vector<>` (beware it has a ctor/initialization cost which goes up the more elements you add).
- Or you may use `boost::container::small_vector<>` (which has an initialization cost as well, and will use extra book-keeping for heap, try to keep a balance).
- Don't use `[[likely]]` or `[[unlikely]]`; PGO builds exist for that.
- Don't use inline assembly to try to outsmart the compiler unless you're 100% sure the assembly you're writing is actually good.
- And if so, try to restructure your C++ code so the compiler vectorizes it/makes it better, right?
- Or if that fails, use intrinsics instead of raw `asm volatile`.
- Use `std::optional<>` instead of `std::unique_ptr<>` if possible.
-`std::unique_ptr<>` carries indirection cost due to it being memory allocated on the heap.
- It isn't often that objects that contain `std::unique_ptr<>`, are allocated on the heap themselves, allocating even more things on the heap seems redundant.
- Avoid `std::recursive_mutex` at all costs.
- It's basically implemented as a linked list most of the time and has HEAVY performance penalties.
- Exploit the fact `std::atomic<uint32_t>/std::atomic<int32_t>` is basically free on most arches that matter.
- In x86_64, an atomic `uint32_t` is basically `mov [m32], r32`, which is essentially free/cheap.
- Avoid template parameters unless you really need them.
- For small inlineable functions this is fine, for more complex ones, please consider the generated assembly.
- Dont make your own memcpy/memset/strcpy/strncpy/etc.
- Seriously DON'T DO THIS. You will NOT beat the compiler.
- Nor 30 years of writing optimized `mem*`.
- If your code is slow, don't blame `mem*`, blame your code.
- Try to avoid using `virtual` since vtable indirection has a cost
- Avoid `dynamic_cast` and `typeid` at all costs.
- The reason is because the project has `-fno-rtti` disabled by default, due to the costs of dynamic polymorphism.
- Always copy-on-value for objects with `sizeof(void *) >= sizeof(T) * 2`, i.e objects sized as 2 pointers or less, for bigger objects you can use ref/pointer as usual.
- Try using move semantics instead of references, whenever possible.
- Remember function parameters are extremelly cheap as fuck, don't be afraid to place upto 8 parameters on a given function.
- Don't save a reference in structures of a parent object, i.e:
```c++
struct Child {
Parent& parent;
void Mehod() {
parent.Something();
}
};
```
- Instead you can do the following:
```c++
struct Child {
void Mehod(Parent& parent) {
parent.Something();
}
};
```
- This reduces the amount of pointers you have lying around, and also works better because of the aforementioned cheapness of parameter functions.
Try not using hungarian notation, if you're able.
# Engineering guidelines
## Formatting
Coding isn't also writing stuff but architecturing stuff, consider the following:
Formatting is extremelly lax, the general rule of thumb is: Don't add new lines just to increase line count. The less lines we have to look at, the better. This means also packing densely your code while not making it a clusterfuck. Strike a balance of "this is a short and comprehensible piece of code" and "my eyes are actually happy to see this!". Don't just drop the entire thing in a single line and call it "dense code", that's just spaghetti posing as code. In general, be mindful of what other devs need to look at.
Do not put if/while/etc braces after lines:
```c++
// no dont do this
// this is more lines of code for no good reason (why braces need their separate lines?)
// and those take space in someone's screen, cumulatively
if (thing)
{ //<--
some(); // ...
} //<-- 2 lines of code for basically "opening" and "closing" an statment
// do this
if (thing) { //<-- [...] and with your brain you can deduce it's this piece of code
// that's being closed
some(); // ...
} //<-- only one line, and it's clearer since you know its closing something [...]
// or this, albeit the extra line isn't needed (at your discretion of course)
if (thing)
some(); // ...
// this is also ok, keeps things in one line and makes it extremely clear
if (thing) some();
// NOT ok, don't be "clever" and use the comma operator to stash a bunch of statments
// in a single line, doing this will definitely ruin someone's day - just do the thing below
// vvv
if (thing) some(), thing(), a2(a1(), y1(), j1()), do_complex_shit(wa(), wo(), ploo());
// ... and in general don't use the comma operator for "multiple statments", EXCEPT if you think
// that it makes the code more readable (the situation may be rare however)
// Wow so much clearer! Now I can actually see what each statment is meant to do!
if (thing) {
some();
thing();
a2(a1(), y1(), j1());
do_complex_shit(wa(), wo(), ploo());
}
```
Brace rules are lax, if you can get the point across, do it:
```c++
// this is fine
do {
if (thing) {
return 0;
}
} while (other);
// this is also ok --- albeit a bit more dense
do if (thing) return 0; while (other);
// ok as well
do {
if (thing) return 0;
} while (other);
```
There is no 80-column limit but preferably be mindful of other developer's readability (like don't just put everything onto one line).
A note about operators: Use them sparingly, yes, the language is lax on them, but some usages can be... tripping to say the least.
```c++
a, b, c; //<-- NOT OK multiple statments with comma operator is definitely a recipe for disaster
return c ? a : b; //<-- OK ternaries at end of return statments are clear and fine
return a, b; //<-- NOT OK return will take value of `b` but also evaluate `a`, just use a separate statment
void f(int a[]) //<-- OK? if you intend to use the pointer as an array, otherwise just mark it as *
```
And about templates, use them sparingly, don't just do meta-templating for the sake of it, do it when you actually need it. This isn't a competition to see who can make the most complicated and robust meta-templating system. Just use what works, and preferably stick to the standard libary instead of reinventing the wheel. Additionally:
```c++
// NOT OK This will create (T * N * C * P) versions of the same function. DO. NOT. DO. THIS.
- While some dependencies are useful `boost::container` and `fmt` to name a few, remember each dependency added incurs a cost.
- It may also be subpar with a hand rolled implementation, biggest exemplar of this is `spirv-tools` providing subpar SPIRV optimizations in comparison to the in-house optimizer.
- Try to rely less on indirection for architecturing systems
- If the underlying HLE kernel emulation requires it, try making a solution that keeps things local
- For example, there isn't a need for file descriptors to each be a pointer, when they could be a fixed table size with elements that may be emplaced at will.
These are mostly "suggestions", if you feel like your code is readable, comprehensible to others; and most importantly doesn't result in unreadable spaghetti you're fine to go.
But for new developers you may find that following these guidelines will make everything x10 easier.
## Naming conventions
Simply put, types/classes are named as `PascalCase`, same for methods and functions like `AddElement`. Variables are named `like_this_snake_case` and constants are `IN_SCREAMING_CASE`.
Except for Qt MOC where `functionName` is preferred.
Template typenames prefer short names like `T`, `I`, `U`, if a longer name is required either `Iterator` or `perform_action` are fine as well. Do not use names like `SS` as systems like solaris define it for registers, in general do not use any of the following for short names:
-`SS`, `DS`, `GS`, `FS`: Segment registers, defined by Solaris `<ucontext.h>`
-`EAX`, `EBX`, `ECX`, `EDX`, `ESI`, `EDI`, `ESP`, `EBP`, `EIP`: Registers, defined by Solaris.
-`X`: Defined by some utility headers, avoid.
-`_`: Defined by gettext, avoid.
-`N`, `M`, `S`: Preferably don't use this for types, use it for numeric constants.
-`TR`: Used by some weird `<ucontext.h>` whom define the Task Register as a logical register to provide to the user... (Need to remember which OS in specific).
Macros must always be in `SCREAMING_CASE`. Do not use short letter macros as systems like Solaris will conflict with them; a good rule of thumb is >5 characters per macro - i.e `THIS_MACRO_IS_GOOD`, `AND_ALSO_THIS_ONE`.
Try not using hungarian notation, if you're able.
## Formatting
Formatting is extremelly lax, the general rule of thumb is: Don't add new lines just to increase line count. The less lines we have to look at, the better. This means also packing densely your code while not making it a clusterfuck. Strike a balance of "this is a short and comprehensible piece of code" and "my eyes are actually happy to see this!". Don't just drop the entire thing in a single line and call it "dense code", that's just spaghetti posing as code. In general, be mindful of what other devs need to look at.
Do not put if/while/etc braces after lines:
```c++
// no dont do this
// this is more lines of code for no good reason (why braces need their separate lines?)
// and those take space in someone's screen, cumulatively
if (thing)
{ //<--
some(); // ...
} //<-- 2 lines of code for basically "opening" and "closing" an statment
// do this
if (thing) { //<-- [...] and with your brain you can deduce it's this piece of code
// that's being closed
some(); // ...
} //<-- only one line, and it's clearer since you know its closing something [...]
// or this, albeit the extra line isn't needed (at your discretion of course)
if (thing)
some(); // ...
// this is also ok, keeps things in one line and makes it extremely clear
if (thing) some();
// NOT ok, don't be "clever" and use the comma operator to stash a bunch of statments
// in a single line, doing this will definitely ruin someone's day - just do the thing below
// vvv
if (thing) some(), thing(), a2(a1(), y1(), j1()), do_complex_shit(wa(), wo(), ploo());
// ... and in general don't use the comma operator for "multiple statments", EXCEPT if you think
// that it makes the code more readable (the situation may be rare however)
// Wow so much clearer! Now I can actually see what each statment is meant to do!
if (thing) {
some();
thing();
a2(a1(), y1(), j1());
do_complex_shit(wa(), wo(), ploo());
}
```
Brace rules are lax, if you can get the point across, do it:
```c++
// this is fine
do {
if (thing) {
return 0;
}
} while (other);
// this is also ok --- albeit a bit more dense
do if (thing) return 0; while (other);
// ok as well
do {
if (thing) return 0;
} while (other);
```
There is no 80-column limit but preferably be mindful of other developer's readability (like don't just put everything onto one line).
A note about operators: Use them sparingly, yes, the language is lax on them, but some usages can be... tripping to say the least.
```c++
a, b, c; //<-- NOT OK multiple statments with comma operator is definitely a recipe for disaster
return c ? a : b; //<-- OK ternaries at end of return statments are clear and fine
return a, b; //<-- NOT OK return will take value of `b` but also evaluate `a`, just use a separate statment
void f(int a[]) //<-- OK? if you intend to use the pointer as an array, otherwise just mark it as *
```
And about templates, use them sparingly, don't just do meta-templating for the sake of it, do it when you actually need it. This isn't a competition to see who can make the most complicated and robust meta-templating system. Just use what works, and preferably stick to the standard libary instead of reinventing the wheel. Additionally:
```c++
// NOT OK This will create (T * N * C * P) versions of the same function. DO. NOT. DO. THIS.
<stringname="your_setting_name_description">Detailed description of what this setting does. Explain any caveats, requirements, or warnings here.</string>
```
---
## Step 4 - Use Your Toggle!
Now the UI part is done find a place in the code for the toggle,
If you wish to do something only when the toggle is disabled,
Use `if (!your_value) {` instead of `if (your_value) {`.
---
## Best Practices
* Naming - Use clear, descriptive names. Something for both the devs and the users.
* Defaults - Choose safe default values (usually false for new features).
* Documentation - Write clear descriptions explaining when and why to use the setting.
* Categories - Put settings in the appropriate category.
* Order - Place related settings near each other.
* Testing - Always test on both PC and Android before committing when possible.
### Thank you for reading, I hope this guide helped you making your toggle!
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.