Fix the bug reported by Pavel in which when per-game settings screen is rotated a reloadGames() call causes external content reference to be missing.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3788
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Co-committed-by: xbzk <xbzk@eden-emu.dev>
crueter will love this one
mcl nuked off externals, i did however copy some important headers (notably intrusive list and bit.hpp); because grand part of dynarmic still uses them
but i made the appropriate adjustments anyways
solves mcl for #3373
depends on #3718
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3777
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
- The Xcode generator /mandates/ that you pass in the `.icon` directory
into the build system, where it can then compose the asset itself.
- Assets.car and eden.icns were improperly handled; they are now
automatically generated and should properly be applied as needed. I
will need someone on Tahoe to confirm, however, as I am on Sequoia.
- Added some missing frameworks, ported from the KosmicKrisp branch.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3782
Complementary for 3750.
User found a way to get same driver doubled and deleting one would lead to a crash.
Reason: manual driver install was still adding drivers directly to adapter, instead of thru drivermodel. fixed.
Also added guards against crash upon driver removal.
Thoroughly tested.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3757
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Co-committed-by: xbzk <xbzk@eden-emu.dev>
Lets do the quick math
There was 1 LUT for every fsize() instancing
Now... the number of functions on each lut was (fsize + 1), multiplied by 5 (number of rounding modes)
8 = 9 * 5 = 45
16 = 17 * 5 = 85
32 = 33 * 5 = 165
64 = 65 * 5 = 325
this is just pure insanity - look at what fucking nm reported:
```
0000000003dc39b8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<16ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a18 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<16ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc39d8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<32ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a38 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<32ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc39f8 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<64ul, false>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
0000000003dc3a58 0000000000000008 V guard variable for void Dynarmic::Backend::X64::EmitFPVectorToFixed<64ul, true>(Dynarmic::Backend::X64::BlockOfCode&, Dynarmic::Backend::X64::EmitContext&, Dynarmic::IR::Inst*)::lut
```
"ah its not bad" - OH MATE ITS JUST THE GUARD VARIABLES - i attached a file with just the functions generated for each case...
now with this PR only 6 * 6 functions are made (still not ideal, but way better), 36 is way better than 1156 FUCKING FUNCTIONS
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3718
Reviewed-by: DraVee <chimera@dravee.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
This Pr is a reply to certain issues found on Android due to the new artificial waits inside Vulkan (Frame Pacing Mode); which caused GPU/CPU desync's even if TimelineSemaphore (Adreno's drivers) does a constant check to retain synchronization with each frame-data, removes the yield() for all platforms (remains the same on PC) and aligns a new way to handle the output of video by using native Android tools, such as AGP, which makes a bridge inside Vulkan to Android's Surface (screen) and reduces not only the latency, but also improves the smoothness of each frame processed; currently we quantize the amount of frame processed by hinting the surface on Android space and adjust the heuristics of the old handling (yuzu) and we link it to screen refresh rate; this way we ensure that even if the game moves below the screen's HZ, we can always pick up the cadence by clamping the duration of each frame and using a chrono function to work as internal fernce if performance goes below the game speed requirment or game's frame rate requirements.
Co-authored-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3735
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: PavelBARABANOV <pavelbarabanov94@gmail.com>
Co-committed-by: PavelBARABANOV <pavelbarabanov94@gmail.com>
