This may reduce total overhead (as benchmarks show boost::container::deque being better performing than std::deque, especially with the limited set of ops like push_front and pop_back
May actually not help at all and be worse through, as always, performance tests are welcome
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3120
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
MediaCodec needs some jvm shenanigans to work, but the others should
Just Work(TM). Need tests on Windows (AMD/Intel), macOS
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3156
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
We had the same struct for v1 and v2 - this was tested only with MP4, should output correct sounds now and boot it.
Co-authored-by: MaranBr <maranbr@outlook.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3142
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: Maufeat <sahyno1996@gmail.com>
Co-committed-by: Maufeat <sahyno1996@gmail.com>
The GPU Accuracy level is now divided into Performance, Balanced and Accurate.
1. Performance prioritizes speed at all costs. It's faster, but it can be unstable and may have some bugs (which is expected).
2. Balanced maintains excellent performance and is safer against bugs and shader corruption.
3. Accurate is the most precise and the most expensive in terms of hardware. Only a few games still need this level to work properly.
The Release Early Fences toggle has also been removed by @PavelBARABANOV, as it's not needed anymore.
Co-authored-by: PavelBARABANOV <pavelbarabanov94@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3129
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Fixes an issue where selecting EDS 0 for a specific game would incorrectly disable VIDS globally.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3148
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Both options do nothing, however one was exposed to the user making them think it actually helps.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3152
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: Kleidis <kleidis1@protonmail.com>
Co-committed-by: Kleidis <kleidis1@protonmail.com>
rationale:
- some drivers will not outright crash (and keeping a list of those who don't crash is tedious)
- if it does crash we can get a log line saying "hey, this driver? unsuitable"
- makes lfie with lavapipe a tad bit easier
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3087
Reviewed-by: crueter <crueter@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>
So when libc starts it has to start at an entry point located into crt0, now most OSes will do "enough" setup to allow mprotect() and mmap() to be called in static ctors (remember they're called BEFORE main)
By some stupid miracle, NetBSD doesn't; this means that using those functions on NetBSD will result in spurious results
The reason why is still unknown to me, but this is also combined with the fact that allocating a big chunk of memory for the JIT will make NetBSD refuse to mprotect()/mmap() it in low memory situations (even when space is available); so I take the same approach as with solaris
Also I now make it so fastmem handlers are NOT registered for OSes that disabled fastmem, this is because they pollute sigsegv and makes debugging stupidier
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3092
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
Never in my lifetime will I ever need to revise anisotropy levels; I hope :)
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3019
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
NOTES:
regs.window_origin.flip_y MUST flip the y coordinate of any given FragCoord, we don't emulate this, this is the root cause of the error, but I'll just revert for now since it's easier
DON'T MERGE unless it's near 0.0.4 and I (or someone else) hasn't tackled this yet properly
This reverts commit 17fe74ef11.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3075
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>
Fixes AMD + Windows because it forces barriers to include the fragment test and color output stages explicitly, ensuring that all render pass writes are visible before later commands. Without it, AMD’s driver sometimes skipped synchronization, causing broken rendering in Final Fantasy Tactics.
PR #3069 also fixes this regression by reverting vk_scheduler.cpp in PR #180.
This PR fixes PR #180 and may be the better solution.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3071
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: John <john@eden-emu.dev>
Co-committed-by: John <john@eden-emu.dev>
This change is intended to fix two regressions:
1. Fixes the issue where `EDS3` + `Vertex Input Dynamic State` being enabled prevented some games from launching correctly.
2. Fixes the issue with broken water in `Super Mario Party Jamboree`.
This complements #3042.
Co-authored-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3068
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
flip_y means "flip the Y coordinate of the triangles"; however, right now we just update the front face... this "emulates" the raster flip in the viewport itself, not the best solution but it's one solution :)
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3058
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
Improves EDS logic and fix some inconsistencies.
Removes a lot of unneeded code.
Adds an option to control the `Vertex Input Dynamic State` extension.
Fixes issues in Pokémon Legends: Z-A on any EDS level.
Co-authored-by: JPikachu <jpikachu.eden@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3042
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Very small code cleanup, also remove `[[unlikely]]` because it doesn't matter + increase latency of audio render when shutting down
Signed-off-by: lizzie lizzie@eden-emu.dev
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3030
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Reviewed-by: crueter <crueter@eden-emu.dev>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
When viewport_scale_offset_enabled is disabled, the fallback path
previously assumed a top-left origin for both viewport and scissor.
This caused incorrect positioning or inverted geometry when the GPU
state expected a lower-left origin.
This change:
- Adjusts viewport setup: if window_origin is lower-left, shift Y and
flip height negative to emulate lower-left in Vulkan’s top-left space.
- Updates scissor setup: recalculates Y for lower-left origin and
ensures width/height fall back to 1 if zero, avoiding invalid extents.
This aligns Vulkan’s viewport/scissor behavior with Maxwell state,
fixing rendering issues in paths without scale/offset enabled.
Co-authored-by: MaranBr <maranbr@outlook.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/294
Co-authored-by: Shinmegumi <shinmegumi@eden-emu.dev>
Co-committed-by: Shinmegumi <shinmegumi@eden-emu.dev>
this pull should impact ninja gaiden ragebound only! it makes it playable past stage 4-1.
it contains a workaround for missing maxwell_3d's iterated_blend functionality, which fixes several graphics all over the game.
the issue causes transparency enabled blends (mostly lighting fx) to be wrongly blended into destination, turning textures into black frames.
in stage 4-1 there are lighthing layers in the foreground, causing sprites layer to become overlapped by these opaque black frames, including entire screen in a mid boss fight, making it unplayable* (players maneuvered by turning immortal option on and swinging sword all around until defeating it).
also only in stage 4-1 the fix has a short drawback: when you buff up next attack these problematique blends will be drawn back as black frames, but only for a split second, so no big deal.
this workaround was already discovered and available in PR 302, but in an unconventional way for a game specific override, so we did forbidden it. now it uses classic game specific override solution exampled in core.cpp's System::Impl::LoadOverrides method, so now i guess it's worth to merge it and deliver this to players until we harness iterated_blend control.
additionally I've slightly reworked vk_rasterizer.cpp's RasterizerVulkan::UpdateBlending, if (state_tracker.TouchBlendEquations()) {...} session.
it was made in a way that for a single blend, it exhaustly calls 48 (6 x 8) MaxwellToVK redundant functions, and declared a lambda function inside a 8 laps loop.
reworked it so that instead of 48 calls it makes only the necessary 6 calls, and then merely safely copy the result for the other 7 times.
Co-authored-by: Allison Cunha <allisonbzk@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2934
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Shinmegumi <shinmegumi@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Co-authored-by: xbzk <xbzk@eden-emu.dev>
Co-committed-by: xbzk <xbzk@eden-emu.dev>
This cleans up the code and fixes some inconsistencies in the EDS settings.
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/3015
Co-authored-by: MaranBr <maranbr@outlook.com>
Co-committed-by: MaranBr <maranbr@outlook.com>
Requires qt6-static, obviously... at least for eden. eden-cli also can
be built fully static
Notable challenges n such:
1. VkMemAlloc conflicts with Qt, since it embeds vk_mem_alloc.h in
qrhivulkan; we can get around this by conditionally defining
VMA_IMPLEMENTATION; that is, define it in the SDL2 frontend and undef
it in the Qt frontend. It's not ideal, but I mean... it works, no?
2. find_library, pkgconfig, and some Config modules will always look for
a .dll, so we have to tell CMake to look for .a
3. In spite of this, some will end up using .dll.a (implib) as their
link targets; this is, well, bad, so we create a find_library hook
that rejects dll.a
4. Some libraries have specific configs (boost lol)
5. Some libraries use _static targets (zstd, mbedtls)
6. Some extra libraries need to be linked, i.e. jbig, lzma, etc
7. QuaZip is sad
Needs testing on all platforms, and for both frontends on desktop, to
ensure Vulkan still works as expected.
(also: CI). Resulting executables are:
- 71MB for eden.exe
- 39MB for eden-cli.exe
Considering the entire libicudt is included (thanks Qt), that's a great size all things considered. No need to bundle all those plugins and translation files too.
Theoretically, this lays the groundwork towards fully static executables for other platforms too; though Linux doesn't have a huge benefit since AppImages are needed regardless. eden-room though maybe?
Fixes comp for clangarm64 because -msse4.1
Also allows macOS to build with qt6-static. macOS can't build static executables, but with these changes it ONLY relies on system libraries like libc and frameworks. So in theory we don't even need macdeployqt.
Signed-off-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2994
Eventually we'd want cmake to do the build for us (as a build step) instead of having git be polluted with commits to update the autogenerated file...
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/2791
Reviewed-by: crueter <crueter@eden-emu.dev>
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Caio Oliveira <caiooliveirafarias0@gmail.com>
Co-authored-by: lizzie <lizzie@eden-emu.dev>
Co-committed-by: lizzie <lizzie@eden-emu.dev>
CamilleLaVey