| Age | Commit message (Collapse) | Author |
|---|
|
Adds support for choosing to present the full resolution
independently to each eye when using side-by-side or
top-and-bottom 3D.
|
|
This causes Dual Core to lock up during the boot sequence, because it tries to wait for a not-yet-running GPU thread.
Fixes https://bugs.dolphin-emu.org/issues/13559
|
|
Some pieces of code are calling IsRunning because there's some
particular action that only makes sense when emulation is running, for
instance showing the state of the emulated CPU. IsRunning is appropriate
to use for this. Then there are pieces of code that are calling
IsRunning because there's some particular thing they must avoid doing
e.g. when the CPU thread is running or IOS is running. IsRunning isn't
quite appropriate for this. Such code should also be checking for the
states Starting and Stopping. Keep in mind that:
* When the state is Starting, the state can asynchronously change to
Running at any time.
* When we try to stop the core, the state gets set to Stopping before we
take any action to actually stop things.
This commit adds a new method Core::IsUninitialized, and changes all
callers of IsRunning and GetState that look to me like they should be
changed.
|
|
Core::GetState reads from four different pieces of state: s_is_stopping,
s_hardware_initialized, s_is_booting, and CPUManager::IsStepping.
I'm keeping that last one as is for now because there's code in Dolphin
that sets it directly, but we can unify the other three to make things
easier to reason about.
This commit also gets rid of s_is_started. This was previously used in
Core::IsRunningAndStarted to ensure true wouldn't be returned until the
CPU thread was started, but it wasn't used in Core::GetState, so
Core::GetState would happily return State::Running after we had
initialized the hardware but before we had initialized the CPU thread.
As far as I know, there are no callers that have any real need to know
whether the boot process is currently initializing the hardware or the
CPU thread. Perhaps once upon a time there was a desire to make the
apploader debuggable, but a long time has passed without anyone stepping
up to implement it, and the way CBoot::RunApploader is implemented makes
it rather difficult. So this commit makes all the functions in Core.cpp
consider the core to still be starting until the CPU thread is started.
|
|
also polish aspect ratio related code for clarity
|
|
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.
|
|
A bit of global state remains (the `header` in `BeginRecordingInput()`) due to unclear lifetime requirements.
|
|
Given how many member functions make use of the system instance,
it's likely just better to pass the system instance in on construction.
Makes the interface a little less noisy to use.
|
|
Also fixes the widescreen hack not fully updating when the aspect ratio setting changed on the spot.
|
|
This also renamed some variables/functions.
|
|
invalidating pipelines when graphic config changes
|
|
values in onion config.
|
|
onion config
|
|
overridden by onion config
|
|
Don't call RunAsCPUThread in config callbacks
|
|
shaders
|
|
|
|
In theory, our config system supports calling Set from any thread. But
because we have config callbacks that call RunAsCPUThread, it's a lot
more restricted in practice. Calling Set from any thread other than the
host thread or the CPU thread is formally thread unsafe, and calling Set
on the host thread while the CPU thread is showing a panic alert causes
a deadlock. This is especially a problem because 04072f0 made the
"Ignore for this session" button in panic alerts call Set.
Because so many of our config callbacks want their code to run on the
CPU thread, I thought it would make sense to have a centralized way to
move execution to the CPU thread for config callbacks. To solve the
deadlock problem, this new way is non-blocking. This means that threads
other than the CPU thread might continue executing before the CPU thread
is informed of the new config, but I don't think there's any problem
with that.
Intends to fix https://bugs.dolphin-emu.org/issues/13108.
|
|
(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>
|
|
... using libadrenotools
|
|
Co-authored-by: Mai <mathew1800@gmail.com>
Co-authored-by: BhaaL <bhaalsen@gmail.com>
Co-authored-by: iwubcode <iwubcode@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
|
|
There is this nice VideoConfig file that's perfect for it
|
|
VideoBackends:Metal: Default to presentDrawable when vsync is on
|
|
Cull vertices on the CPU
|
|
|
|
|
|
|
|
|
|
|
|
Needed by M1 fifoci to work around a minor non-determinism bug
|
|
|
|
Various Metal renderer improvements
|
|
|
|
|
|
Turns out it was helpful. (Most improvement in ubershaders.) This time with much better auto mode.
|
|
Texture dumping can already be done using VideoCommon's system (and in fact the same setting already enabled *both* of these). Dumping objects/TEV stages/texture fetches doesn't currently have an equivalent, but could be added to the FIFO player instead.
|
|
read brand_string on macos/arm64
remove unused flags
report family/model info instead of vendor name
|
|
|
|
... and refresh the config before populating the backend info, as the config (specifically iAdapter) needs to be set to correctly populate the backend info.
Before, the list of valid antialiasing modes was always determined from the first adapter on the list on startup, regardless of the adapter the user selected.
|
|
This is mainly for debugging, and is only exposed by manually editing the configuration.
|
|
Software: Fix zfreeze with CullMode::All
|
|
VideoCommon/FrameDump: Allow user to specify a pixel format.
|
|
These aren't particularly useful, and make the code a bit more confusing. If for some reason someone wants to test what happens when these functions are disabled, it's easier to just edit the code that implements them. They aren't exposed in the UI, so one would need to restart Dolphin to do it anyways.
|
|
|
|
|
