a bit of refactoring so there's less code duplication...
probably a good idea to make it a lambda anyways
maybe this is why QLauncher didn't have proper DLCs and updates?
either way "GetPseudoDeviceId" is now implemented (still stubbed) with a proper hash instead of just 0
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4159
Reviewed-by: Maufeat <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
loader is barely called whereas audio for example is called super often
thus demote loaderr
jit is only ever used by Super Mario 3D stars, and no other
games require this to be a separate jit thread
additionally even of 3D stars this is called often chary
so no; we dont need a dedicated thread for it either way
this pr should help low power devices/devices with less cores/threads
to schedule the existing emulator threads more efficiently
also moving to guest means the CPU threads get more loaded with
stuffings, which is a good thing as most of the time theyre
sleeping and/or waiting for a mutex
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4148
Reviewed-by: Maufeat <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
take If{then, else} for example
100% of the time If{} only has a leaf terminal, supporting If{If{}, If{}} is very dumb and we don't need that
so remove that
this reduces
> The recursive_wrapper class template has an interface similar to a simple value container, but its content is allocated dynamically
aka. uses malloc and spams heap EVERYTIME A CONDITIONAL TERMINAL IS USED
thats bad tbf, i dont like it, removing it is better for general speedup
also we dont REALLY need if{if{if{if{}}}} support, like really
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4218
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: Maufeat <[email protected]>
if we are REALLY going thru for removing the entire game compat list
subsystem, we ought to remove the setting itself
I kept this PR separate because we MAY want to introduce emuready
compatibility, so keeping the setting will keep compatibility with
older setting files from users...
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4202
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
we have no use for it
it's dead code
most of the time users just complain about how the list isn't updated
ok so what if we update it? great now its more noise added to the git, awesome
even if we constantly update it, we introduce new breakage that makes keeping
track of things extremely difficult
either we integrate with emuready (would violate self containment principles)
or we integrate with emuready in a similar fashion to eden news outlet
(where we cache the list with some TTL of like 60 mins or whatever)
that would be better respecting of "self containment" but would probably
require having a quick way to update the list additively, probably filtered to the user's
device instead of a global thing, and i dont think emuready has that granularity
nor we have the "connect this to that" for the api stuffs
another (which is what i propose here) is throw everything out of the window
until someone can come up with something better
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4201
Reviewed-by: Maufeat <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
this was only ever used for announce room json on one single instance
this object is pretty much a danger to society and shouldnt exist, especially since its:
a) a singleton
b) spawns objects out of thin air
c) doesn't respect RAII and can outlive its parent objects (big no no)
generally we shouldnt endorse objects like these in the future, but alas, it existed, now it has to begone
additionally there is a similar object in KWorkerTaskManager but it's not as egregious as this one.
check that this didnt break the usual announce room json logic
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4096
Reviewed-by: CamilleLaVey <[email protected]>
Reviewed-by: MaranBr <[email protected]>
SURELY, microslop already fixed its megaslop?
basically read the comment (now gone); MSVC is evil, but it cant still be this evil right... right?!?!?! it's been 2 years surely not!
mainly because this helps deep scan (in theory); android should see slight improvments for big game libraries
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3670
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
while this may be true, it isn't required to have this quick path for this function because:
a) arm64
b) counter/freq and counter%freq is a single idiv
c) 2 muls, 2 div isnt that insanely expensive
d) `static_assert(period::den % TenMHz == 0)`
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4162
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
small oopsie; we dont need 6 copies of the same 22KB table
(removes 5*22 = 110 KB worth of redundant stuff)
this also enforces static on the types defined in the header so they arent memoized into a non-inlined value (aka. compiler just grabs value instead of well, yknow, assuming its a constant area)
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4180
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4093
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: Maufeat <[email protected]>
should fix some issues with some NAS setups
where people have their games on a NAS and they
try to access it but for some reason some file
just doesnt load, instead of aborting early we continue
for the rest of the files in the directory
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4100
Reviewed-by: Shinmegumi <[email protected]>
Reviewed-by: Maufeat <[email protected]>
samu will be happy
basically this handles the edge case where either:
a) eden is the first application ever ran (i.e no config dirs made yet)
b) user didnt have them
c) user is trying to run on a sandbox appimage or whatever bs
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4087
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3894
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3969
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3984
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3874
Reviewed-by: crueter <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
Reviewed-by: MaranBr <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4006
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
- testriswitch submits buffers with a fence id of -1, just skip them instead of trying to process them?
- apm:u, which is removed, but hey, backwards compat never hurted
- another instance of shared_memory crashing NPad
Signed-off-by: lizzie <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3983
Reviewed-by: MaranBr <[email protected]>
Reviewed-by: CamilleLaVey <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3970
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3981
Reviewed-by: Maufeat <[email protected]>
Reviewed-by: crueter <[email protected]>
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 [email protected]
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3237
Reviewed-by: Ghost <>
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3716
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3605
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3866
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3919
Reviewed-by: crueter <[email protected]>
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 <[email protected]>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3954
Reviewed-by: crueter <[email protected]>
Reviewed-by: MaranBr <[email protected]>
lizzie
