Calling deleteLater in MainWindow's destructor doesn't work, as the
event loop will stop before it gets around to deleting these dialogs.
Seeing as this is a QObject destructor, we should already be on the
event loop anyways, so simply using delete should be safe.
Doing pretty much anything in the controller config breaks NetPlay
(desync and/or deadlock), as saving the settings reconfigures
controller interfaces, which NetPlay doesn't expect.
Previously, the Qt frontend would initialize the controller
interface on starting, resulting in the cursor position being
relative to the main window, instead of the render window.
* Removed the Cancel button since the code doesn't react to it anyway.
* Only show a window title, not the help icon (?), and disable the close button
* Set the title to "Dolphin" instead of repeating the label text
also did these things
fixed crash from joining user that isn't hosting via a direct connection
current game stat can now pass to override the current game in config
uses ip endpoint from dolphin.org
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 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.
Reduces the amount of dependencies dragged in by the main window's
header. This also removes MainWindow.h includes elsewhere where they
aren't necessary, reducing the amount of UI files that need to be
recompiled if the main window's header changes.
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.
JosJuice