| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
with ImmediateXFB and/or RushFramePresentation.
|
|
usage of GetTicks() with ImmediateXFB + DualCore.
|
|
after each presentation for lower input latency.
|
|
VideoCommon: pass the EFB buffer scale into the FramebufferManager
|
|
|
|
of pulling it from config, in the future this will allow us to have multiple framebuffers
|
|
Co-authored-by: Dentomologist <dentomologist@gmail.com>
|
|
|
|
thread.
|
|
|
|
|
|
Adds support for choosing to present the full resolution
independently to each eye when using side-by-side or
top-and-bottom 3D.
|
|
VideoCommon: add xfbs hashes to present info if available
|
|
|
|
|
|
screenshots and not videos (only videos encoders have this limit).
NOTE: this will likely trigger FIFOCI differences.
|
|
also polish aspect ratio related code for clarity
|
|
which also avoids the output window from being resized randomly to be a multiple of 4
|
|
resolution, avoiding any scaling if possible.
This should make comparisons much more reliable as pixels wouldn't be smushed together or stretched.
|
|
|
|
they are within a ~1 pixel treshold on one axis only.
This takes care of making the image clearer in some edge cases where the game was already running at near perfect
4:3 with no stretching, and the VI aspect ratio didn't match the XFB by one pixel, making the image stretched and blurry.
-Video: Fix `FindClosestIntegerResolution() using the window aspect ratio and not the draw aspect ratio, causing it to prefer
stretching over black bars in cases when it wasn't desirable.
|
|
Instead, we make the event take a reference to the system and then pass
it in when the event is triggered.
This does introduce two other accessors, but these are much easier to
refactor out over time, and without modification to the existing event
interface.
|
|
to avoid trying to create texture bigger than the maximum supported one
|
|
|
|
Also fixes the widescreen hack not fully updating when the aspect ratio setting changed on the spot.
|
|
This also renamed some variables/functions.
|
|
|
|
There's no need to self reference a global of the class itself when we
can just call the function directly.
|
|
This triggers an assert in TCacheEntry::SetXfbCopy() otherwise if you load a savestate that was made before the first XFB has been rendered.
|
|
the window weird aspect ratios (e.g. 32:9), beacuse it would account for the the portion of the image that will show black bars into the calcuations to find the best matching resolution
|
|
based on the resolution of the window in the previous frame if we used the "stretch" aspect ratio setting, so it's result would be self influence in a loop and behave unreliably (e.g. when changing resolution between Auto/Native/2x the automatic window scaling would behave randomly)
|
|
(top/left/bottom/right) of the window because the final output size wasn't calculated right (unless the aspect ratio was set to stretch)
|
|
be done when recording videos (due to encoding limitations) but one case was missed (this had no consequences really, as it was just in the code that automatically resizes the window). The hardcoded `4` has been replaced with `VIDEO_ENCODER_LMC` for clarity.
|
|
(and gamma) that GC and Wii targeted.
To further increase the accuracy of the post process phase, I've added (scRGB) HDR support, which is necessary
to fully display the PAL and NTSC-J color spaces, and also to improve the quality of post process texture samplings and
do them in linear space instead of gamma space (which is very important when playing at low resolutions).
For SDR, the quality is also slightly increased, at least if any post process runs, as the buffer is now
R10G10B10A2 (on Vulkan, DX11 and DX12) if supported; previously it was R8G8B8A8 but the alpha bits were wasted.
Gamma correction is arguably the most important thing as Dolphin on Windows outputted in "sRGB" (implicitly)
as that's what Windows expects by default, though sRGB gamma is very different from the gamma commonly used
by video standards dating to the pre HDR era (roughly gamma 2.35).
Additionally, the addition of HDR support (which is pretty straight forward and minimal), added support for
our own custom AutoHDR shaders, which would allow us to achieve decent looking HDR in Dolphin games without
having to use SpecialK or Windows 11 AutoHDR. Both of which don't necessarily play nice with older games
with strongly different and simpler lighting. HDR should also be supported in Linux.
Development of my own AutoHDR shader is almost complete and will come next.
This has been carefully tested and there should be no regression in any of the different features that Dolphin
offers, like multisampling, stereo rendering, other post processes, etc etc.
Fixes: https://bugs.dolphin-emu.org/issues/8941
Co-authored-by: EndlesslyFlowering <EndlesslyFlowering@protonmail.com>
Co-authored-by: Dogway <lin_ares@hotmail.com>
|
|
Improved DPI change handling
|
|
|
|
To maintain compatibility with some video encoders, the whole output buffer was scaled to be a multiple of 4.
This change makes it so that that rule only applies while actively recording (or taking screenshots, even if it might not be necessary for that case).
|
|
|
|
This also needs to be handled on the software renderer path.
|
|
When that setting is enabled, m_xfb_entry is initially not present (during the phase where a shader compilation progress bar would be shown). The main path checks for m_xfb_entry, but the software renderer fallback path didn't.
Fixes another aspect of https://bugs.dolphin-emu.org/issues/13172.
|
|
Fixes issue with post-processing not working
|
|
|
|
|
|
Frame duplicate detection was inverted. Huge problem for 60fps games
where it would see all frames as "duplicates" and nothing would ever be
presented.
|
|
It's about the only thing left in renderer
|
|
|
|
|
|
We don't want to move it, because we want to complete
this refactor without changing savestate version
|
