* Add option for showing the overlay behind the menu
This commit lays the groundwork for this option. Support for this option
in the video drivers themselves is going to be added in later commits.
* gl1: Add overlay behind menu support
* gl2: Add overlay behind menu support
* gl3: Add overlay behind menu support
* vulkan: Add overlay behind menu support
* ctr: Add overlay behind menu support
* d3d9: Add overlay behind menu support
* d3d10: Add overlay behind menu support
* d3d11: Add overlay behind menu support
* d3d12: Add overlay behind menu support
* CHANGES.md: overlay behind menu
Co-authored-by: MrHuu <MrHuu@users.noreply.github.com>
Co-authored-by: Tony <45124675+sonninnos@users.noreply.github.com>
The emulating mailbox infrastructure is very hacky and needs a rethink
to be able to properly support screenshots. emulating mailbox is pretty
nasty to begin with and should be considered a hack.
* Add HDR support
* Attempt to fix Mingw build and Metal builds
* (D3D12) Fix relative header includes
* Add missing hdr_sm5.hlsl.h
* (d3d12_common.c) Some C89 build fixes
* Fix MSVC build
* - Attempt to fix build on mingw/msys unix with dirty hack
- Fix shader compilation of hdr_sm5.hlsl.h on MSVC/Visual Studio -
the define was seen as an error and was causing the first pipeline
to error out
- Make sure we manually set handle of backBuffer to NULL
* Moving the release of the texture above the freeing of desc.srv_heap
and desc.rtv_heap solves the hard crashes on teardown/setup in RA -
it was crashing hard in d3d12_release_texture before
* Add HAVE_D3D12_HDR ifdef - needs to be disabled for WinRT for now
because of several things that are Windows desktop-specific right now
(GetWindowRect)
* Add dirty GUID hack - should work for both mingw/msys on Windows/Linux
as well as MSVC/Visual Studio (hopefully)
* Change HAVE_D3D12_HDR to HAVE_DXGI_HDR
* Move away from camelcase named variables
* Fix RARCH_ERR logs - they need a newline at the end
* d3d12_check_display_hdr_support - make it return a bool on return
and set d3d12->hdr.support and d3d12->hdr.enable outside of the
function
* (DXGI) Remove D3D12 dependencies from dxgi_check_display_hdr_support and
move it to dxgi_common.c instead
* (DXGI) move d3d12_swapchain_color_space over to dxgi_common.c and
rename it dxgi_swapchain_color_space
* (DXGI) move d3d12_set_hdr_metadata to dxgi_common.c and
rename it dxgi_set_hdr_metadata
* (DXGI) dxgi_check_display_hdr_support - better error handling?
* Fix typo
* Remove video_force_resolution
* (D3D12) Address TODO/FIXME
* (D3D12) Backport
c1b6c0bff2
- Fixed resource transition for present when HDR is off
Fixed cel shader displaying all black as blending was enabled when the hdr shader was being applied - turned off blending during this shader
* Move d3d12_hdr_uniform_t to dxgi_common.h and
rename it dxgi_hdr_uniform_t
* (D3D11) Add HDR support
* Add TODO/FIXME notes
* Cache hdr_enable in video_frame_info_t
* Update comment
At best, this results in junk on screen, at worst we could crash.
It's not a perfect fix, there's still a scenario where this breaks: when
fast forwarding is enabled, and we swap from vsync-off to vsync-on when
pausing/rendering the menu, the swap chain (and textures) gets
recreated, and the frame data is completely lost.
There isn't much we can do about this without more intrusive changes,
such as preserving the textures inbetween swap chain reinits.
BFI support added for 180hz / 240hz / etc. Solves issue with image retention from voltage issues at 120hz BFI. Also disabled BFI while in menu, as if set to an incorrect value for the current refresh rate, could cause severe flickering and difficulty reverting to the correct value.
- move shader flags from the video drivers to the context drivers
- rework config_load_shader_preset() from configuration.c into retroarch_load_shader_preset() in retroarch.c with proper compatibility check
- implicitly call retroarch_load_shader_preset() in retroarch_get_shader_preset() once per core/content life cycle
- use video_shader_is_supported() instead of video_driver_test_all_flags() where appropriate
- remove GFX_CTX_FLAGS_NONE because it is meaningless
- gl.c: refactor backend fallback into more general gl2_get_fallback_shader_type
- d3d9-12, gl_core, gx2_gfx, gl, vulkan: more consistent shader init and `set_shader` behavior
- configuration.c: remove check_shader_compatibility
- shader_glsl.c, shader_gl_cg.c: use `video_shader_get_type_from_ext`
- shader_gl_cg.c: add shader type check with fallback to stock like in shader_glsl.c
- menu_shader.c: use `enum rarch_shader_type` instead of `unsigned`
- video_shader_parse.c: add `video_shader_to_str` for easier logging
- remove `type` from `struct video_shader`, which was always set to CG and wrongly used in lang_process.cpp's `slang_process()` (has no further consequences because the code is unused)
- video_shader_parse_type()'s fallback only worked for NULL paths and was wrongly used, now returns RARCH_SHADER_NONE like video_shader_get_type_from_ext().
- video_shader_get_type_from_ext() should not be checking video driver flags, this is instead done by video_shader_is_supported()
- video_driver_get_all_flags() did not actually 'get' flags, changed to video_driver_test_all_flags()
workaround for crash due to glcore not always using at least OpenGL 3.2
- Use VkBuffer instead of linear VkImage for staging uploads.
Not guaranteed to be supported, and desktop IHVs recommend using
buffers.
- Fix validation error where swapchain recreation with reuse of the old
VkSwapchainKHR does not create a fence properly, leading to validation
error next time that swapchain index is observed.
RetroArch will crash in several places when running vulkan in an
environment that does not have working vulkan drivers.
This should guard against those crashes and allow RetroArch to fail
safely in those cases.
Nikos Chantziaras