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...
Core::PauseAndLock requires all calls to it to be balanced, like this:
const bool was_unpaused = Core::PauseAndLock(true);
// do stuff on the CPU thread
Core::PauseAndLock(false, was_unpaused);
Aside from being a bit cumbersome, it turns out all callers really
don't need to know about was_unpaused at all. They just need to do
something on the CPU thread safely, including locking/unlocking.
So this commit replaces Core::PauseAndLock with a function that
makes both the purpose and the scope of what is being run on the
CPU thread visually clear. This makes it harder to accidentally run
something on the wrong thread, or forget the second call to
PauseAndLock to unpause, or forget that it needs to be passed
was_unpaused at the end.
We also don't need comments to indicate code X is being run on the
CPU thread anymore, as the function name makes it obvious.
This changes the main IOS code (roughly the equivalent of the kernel)
to a class instead of being a set of free functions + tons of static
variables.
The reason for this change is that keeping tons of static variables
like that prevents us from making an IOS instance and reusing IOS
code easily.
Converting the IOS code to a class also allows us to mostly decouple
IOS from the PPC emulation.
The more interesting changes are in Core/IOS/IOS. Everything else is
mostly just boring stuff required by this change...
* Because the devices themselves call back to the main IOS code
for various things (getting the current version, replying to a
request, and other syscall-like functions), just like processes in
IOS call kernel syscalls, we have to pass a reference to the kernel
to anything that uses IOS syscalls.
* Change DoState to save device names instead of device IDs to simplify
AddDevice() and get rid of an ugly static count.
* Change ES_Launch's ack to be sent at IOS boot, now that we can do
this properly.
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.
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.
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.
IPC_HLE is actually IOS HLE. The actual IPC emulation is not in
IPC_HLE, but in HW/WII_IPC.cpp. So calling IPC_HLE IOS is more
accurate. (If IOS LLE gets ever implemented, it'll likely be at
a lower level -- Starlet LLE.)
This also totally gets rid of the IPC_HLE prefix in file names, and
moves some source files to their own subdirectories to make the file
hierarchy cleaner.
We're going to get ~14 additional source files with the USB PR,
and this is really needed to keep things from becoming a total pain.
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.
Leo Lam