Per-Game settings now load the settings in this order
1. Emulator Settings
2. Default Settings of the Game that we ship with Dolphin
3. Custom game settings the user have
where the later always overides the former in case of collision, then
we show that on the UI to make it clear to the user which settings being
used.
Behaviorally, this belongs within the netplay client. The server will
always transmit a known RTC value, so it doesn't even need a global for
this. Given the client receives the packet containing said RTC value, we can
store it as a member variable and provide an accessor for reading that
value.
This removes another global variable within the netplay code.
Some of the write checks do an & on the result, returning 0 will allow these fails to be caught.
Updated the default WiimoteNew to set wiimotes 2-4 to be disabled on new install. No reason to have these
enabled unless there is actually a 2+ players
Apparently there was a different section names used by the custom game
settings that caused Android to have those settings broken for
some sections like the graphics one. This adds the map between the generic
settings <> custom settings.
1. Create Settings class the encaupslate the loading/saving of all settings
2. Decouple the logic of saving the settings into 3 different config files
from the UI code.
A little background: Android has 8 controller setup, 4 gamecube pads and 4 wiimote pads. When the static GCPadNew.ini and wiimotenew.ini is created, pads 0-3 are gc 1-4, and 4-7 are wii 1-4. Problem was the settings set wii controllers as pads 1-4, instead of 4-7. So any setting for wiimote1, was set for gc2(padID 1). Which is why the only wiimote to work was 4, since it mapped to padID 4, which is actually wiimote1.
The idea of this code was to not unroll loops, but it was completely broken.
So we've unrolled all loops, but only up to the second iteration.
Honestly, a better check would test if we branch to code which is already in the compiling block. But this is out of scope for now.
But testing shows that this unrolling actually improve the performance. So instead of fixing this bug, this check can be dropped.
Most settings which affect determinism will now be synced on NetPlay.
Additionally, there's a strict sync mode which will sync various
enhancements to prevent desync in games that use EFB reads.
This also adds a check for all players having the IPL.bin file, and
doesn't load it for anyone if someone is missing it. This prevents
desyncs caused by mismatched system fonts.
Additionally, the NetPlay window was getting too wide with checkboxes,
so FlowLayout has been introduced to make the checkboxes take up
multiple rows dynamically. However, there's some minor vertical
centering issues I haven't been able to solve, but it's better than a
ridiculously wide window.
This is accomplished by having SConfig::GetDirectoryForRegion no longer
return nullptr, as doing that was kind silly, considering we never
check for nullptr.
Basically everything here was race conditions in Qt callbacks, so I changed the client/server instances to std::shared_ptr and added null checks. It checks that the object exists in the callback, and the shared_ptr ensures it doesn't get destroyed until we're done with it.
MD5 check would also cause a segfault if you quit without cancelling it first, which was pretty silly.
This option completely disabled the DCBZ instruction. Users are toggling
this option in dolphin forks and using that same problematic config when
launching dolphin. Removing the option from dolphin will let the config be
ignored.
This adds the functionality of sending the host's save data (raw memory
cards, as well as GCI files and Wii saves with a matching GameID) to
all other clients. The data is compressed using LZO1X to greatly reduce
its size while keeping compression/decompression fast. Save
synchronization is enabled by default, and toggleable with a checkbox
in the NetPlay dialog.
On clicking start, if the option is enabled, game boot will be delayed
until all players have received the save data sent by the host. If any
player fails to receive it properly, boot will be cancelled to prevent
desyncs.
