Also clean up the way the system menu label is updated. We don't want
to access the NAND while emulation is running, and especially not
that many times per second on an unpredictable timing.
Old versions of Dolphin are so broken regarding NAND handling that
we need this to repair common issues and avoid issues with titles
like the System Menu or the Wii Shop.
This isn't an exhaustive check, but this will catch most issues
and offer to fix them automatically (if possible).
I don't know who thought it would be a good idea to put the Wiimote
connect code as part of the Host interface, and have that called
from both the UI code and the core. And then hack around it by having
"force connect" events whenever Host_ConnectWiimote is called
from the core...
* Move out boot parameters to a separate struct, which is not part
of SConfig/ConfigManager because there is no reason for it to
be there.
* Move out file name parsing and constructing the appropriate params
from paths to a separate function that does that, and only that.
* For every different boot type we support, add a proper struct with
only the required parameters, with descriptive names and use
std::variant to only store what we need.
* Clean up the bHLE_BS2 stuff which made no sense sometimes. Now
instead of using bHLE_BS2 for two different things, both for storing
the user config setting and as a runtime boot parameter,
we simply replace the Disc boot params with BootParameters::IPL.
* Const correctness so it's clear what can or cannot update the config.
* Drop unused parameters and unneeded checks.
* Make a few checks a lot more concise. (Looking at you, extension
checks for disc images.)
* Remove a mildly terrible workaround where we needed to pass an empty
string in order to boot the GC IPL without any game inserted.
(Not required anymore thanks to std::variant and std::optional.)
The motivation for this are multiple: cleaning up and being able to add
support for booting an installed NAND title. Without this change, it'd
be pretty much impossible to implement that.
Also, using std::visit with std::variant makes the compiler do
additional type checks: now we're guaranteed that the boot code will
handle all boot types and no invalid boot type will be possible.
This is something that should be the responsibility of the frontend
booting the game. Making this part of the host 'interface' inherently
requires frontends to leak internal details (much like the other
UI-related functions in the interface).
This also decouples more behavior from the debugger and the
initialization process in the wx frontend. This also eliminates several
usages of the parent menubar in the debugger code window.
Simple quality-of-life addition that allows "uninstalling" WADs
(removing the corresponding installed title) from the NAND.
The option is only enabled when the WAD can be uninstalled
The motivation for this is actually to encourage proper usage of the
WAD launch feature (installing it to the NAND first), so we can
drop the "direct WAD title launch" hack.
When playing a game on OS X, although the screen does not go to
sleep, the screensaver is still enabled, and therefore, during
gameplay, the screensaver may start running, which is not in
accordance to the behaviour on other other environments (Windows
and X11). It can be argued that the screensaver interrupting
gameplay is a nuissance to many players.
The changes in this commit are intended to allow Dolphin to disable
the screensaver during gameplay, just as intended on other platforms.
The changes have been tested on OS X 10.11 (El Capitan).
Rather than destroy and reinitialize the dialog whenever it's closed,
and opened this dialog can just be hidden from view when it's not
needed, and shown again when it is needed.
Also, a dialog should really not be managing any live instances of
itself, including the one directly in the main frame.
This gets rid of another usage of the main frame global.
Amends the TAS callbacks to internally store functions using
std::function instead of raw function pointers. This allows binding
extra contextual state via lambda functions, as well as keeping the
dialogs internal to the main frame (on top of being a more flexible
interface).
This is currently unused and shouldn't actually be a part of the frame's
public interface. The event system should be used instead to dispatch
messages to the game list control if necessary.
Any functions left exposed are used elsewhere through the main_window
global. May as well prevent any more functions from being used in that
manner where possible.
Utilizes the event system (which is what should have been done here
initially), in order to prevent coupling between two different window frames.
This also makes booting games more versatile using the UI event system,
as the event can just act as a carrier for the filename, making directly
calling boot functions unnecessary. All that's needed is for the event to
propagate to the frame.
This fixes a bug which caused Movie (input recording or playback) or
netplay not to be stopped. DolphinWX previously triggered a STM power
event, and then the STM directly stopped the emulation; the code
which stops Movie/Netplay was completely skipped.
This is fixed by moving it /before/ sending the shutdown event.
OnBootDrive used the "drives" member std::vector for drive paths, but
since PR #4363, this vector is not populated anymore, so we were
accessing it out of bounds.
Actually, drives was not needed in the first place, since we can
get the wxMenu from the event, and from there, get the label directly.
This eliminates public usage of the GetMenuBar() function in CodeWindow.
The benefit of this is it also gets rid of the need to perform direct
access across the config dialog and the main frame. It also gets rid of
the use of the main_frame global.
GetMenuBar() will be removed entirely from CodeWindow in a follow-up that
also removes any related remnants of code made obsolete with its removal.
Léo Lam