This stops clients randomly deadlocking when a spectator leaves, as the mappings construct is not thread-safe and should not be written while the game is running.
Avoids dragging in a bunch of includes from the header files, and also
reduces the amount of files that need to be recompiled if one of those
included headers' source content is ever changed.
Previously we wouldn't indicate if saving or loading these files
happened to fail. In some cases we'd only print out to the logger, but
this is a pretty poor way to tell a user of the interface that something
went wrong in a direct way (the logging messages aren't able to be localized
either).
This packet is only used by the host to detect desyncs, and we don't really need to know the exact frame we desynced on (unless you're debugging, but you can just recompile for that), so it's perfectly fine to just send it less often. This makes it so the timebase packet is sent only every 60 frames, rather than every frame, which further cuts back on unnecessary bandwidth consumption.
define how many frames constitute a high or a low swing/shake when the
button is down. Also configurable is the number of frames to execute
the swing/shake after the button is released.
When disabled only inputs from TAS dialog are used.
When enabled inputs from TAS dialog are used, except when a change in
input is detected from a real controller, in this case the TAS value is
replaced with the real controller value.
Previously there was only one function under the NetPlay namespace,
which is kind of silly considering we have all of these other types
and functions existing outside of the namespace.
This moves the rest of them into the namespace.
This gets some general names, like Player, for example, out of the global namespace.
Works around a bug in QtCore that will cause crashes when
QFileSystemWatcher::addPath is called on a directory that is located on a
removable device (USB mass storage devices, etc.)
This should make the NetPlay dialog appear as a separate window in the taskbar on most systems, which makes more sense than a parented dialog as the user will leave it open for an extended period.
We want this setting to invalidate the cache because it may affect the appearance of textures in the rendered scene, therefore one would expect changing it while the game is running to have the expected effect immediately.
Initializing GraphicsWindow layout & children requires cooperation from
the graphics stack: on my system, for example, it causes a Vulkan
context to get created in order to get driver info. This is a slow
operation, and right now it is taking about 60-70% of the Dolphin
startup time on my system.
Move instead to a lazy-initialization model where the constructor
does nothing, instead offloading work to a separate Initialize() method
called before the window is shown.
I would expect this should be done for other larger parts of the UI,
especially the ones where creating widgets ends up triggering large IO
subsystems (I suspect controller configuration might be doing that).
(I'm not super happy with how this is implemented, but right now it's a
one-off, and it's a major complaint users have with the new UI. I
prioritized getting something working quickly...)
Now the detection heuristic has changed, the old value is no longer
valid.
Some example thresholds for known mipmap effects that should trigger:
SMG's lava has a mimimum difference of ~17.8, SMG2's clouds have a
minimum difference of ~14.8, and Wind Waker's foam has a minimum
difference of ~15
Non-triggering examples were tested and all had a calculated difference
lower than 3.
So a value of 14 should lean towards false-negatives instead of
positives, but this is clearly incomplete testing and may require
further tweaks later.
This no longer converts from sRGB to linear for the reference mip
downsample - even if the original mipmap creation tool used an sRGB
colorspace (which isn't really guaranteed, and may even change per
game), this is a "fast" heuristic that's only an estimate anyway.
The average diff is also now stored in a u64, avoiding floating point
calculations in the per-pixel hot loop.
This should speed up the detection significantly, hopefully fixing
jank when loading in new textures.
Since we don't have proper confuguration file of what to include/exclude
in the backup, this better be disabled because it will lead to unexpected
state. This will solve any issue that was keep hapenning even after fresh
install of the emulator until you manually clear the app data.
spycrab