Turns out it is completely unneeded and it actually works better
*without* it.
Just try launching the system menu from the HBC; in current master, it
will disconnect the remote and not connect it automatically again. With
this change, it will.
The recent IOS initialization changes caused the Bluetooth device to
no longer exist before "starting" IOS (as it should be…), which meant
that Core could not activate Wii remotes during the boot process
anymore.
But that is actually completely useless, because we can just have the
emulated Bluetooth code itself activate Wii remotes as appropriate,
at the right moment.
We can return early from invalid conditions, which allows getting rid
of quite a few levels of indentation.
And let's not duplicate the new_position > file_size check.
ControllerEmu::Control instances have a unique_ptr<ControlReference>
member, which is passed either an InputReference or OutputReference.
Without this virtual destructor, deleting a derived class through a
pointer to the base class is undefined behavior.
This prevents Dolphin from writing to /sys/uid.sys (on the host; root
partition) when installing a WAD before starting emulation, because
the session root is not initialized at that moment.
Incidentally, this also gets rid of a singleton.
instruction tables
Previously, all of the internals that handled how the instruction tables
are initialized were exposed externally. However, this can all be made
private to each CPU backend.
If each backend has an Init() function, then this is where the instruction
tables should be initialized, it shouldn't be the responsibility of
external code to ensure internal validity.
This allows for getting rid of all the table initialization shenanigans
within JitInterface and PPCTables.
Check UsbDK availability at run time and activate UsbDk backend when
possible.
Fall back to current behavior when UsbDK not installed.
Signed-off-by: Dmitry Fleytman <dfleytma@...>
Signed-off-by: Sameeh Jubran <sameeh@...>
ControllerEmu, the class, is essentially acting like a namespace for
ControlGroup. This makes it impossible to forward declare any of the
internals. It also globs a bunch of classes together which is kind of a
pain to manage.
This splits ControlGroup and the classes it contains into their own source
files and situates them all within a namespace, which gets them out of
global scope.
Since this allows forward declarations for the once-internal classes, it
now requires significantly less files to be rebuilt if anything is changed
in the ControllerEmu portion of code.
It does not split out the settings classes yet, however, as it
would be preferable to make a settings base class that all settings derive
from, but this would be a functional change -- this commit only intends to
move around existing code. Extracting the settings class will be done in
another commit.
Several of the things done while performing a scan are logically their own
behavior (e.g. loading a titles file, checking if an entry should be added, etc).
The three parameter AnalogStick constructor takes an internal name, a
display name, and a default radius argument. The delegated constructor is
the one that calls the ControlGroup constructor, setting the group type,
so passing the group type here is a logic bug.
The only reason this appeared to work despite this bug is because
GROUP_TYPE_STICK has a value of 1, and the default radius value used for
attachment sticks is 1.0.
This implements MIOS's PPC bootstrapping functionality, which enables
users to start a GameCube game from the Wii System Menu.
Because we aren't doing Starlet LLE (and don't have a boot1), we can
just jump to MIOS when the emulated software does an ES_LAUNCH or uses
ioctlv 0x25 to launch BC.
Note that the process is more complex on a real Wii and goes through
several more steps before getting to MIOS:
* The System Menu detects a GameCube disc and launches BC (1-100)
instead of the game. [Dolphin does this too.]
* BC, which is reportedly very similar to boot1, lowers the Hollywood
clock speed to the Flipper's and then launches boot2.
* boot2 sees the lowered clock speed and launches MIOS (1-101) instead
of the System Menu.
MIOS runs instead of IOS in GC mode and has an embedded GC IPL (which
is the code actually responsible for loading the disc game) and a PPC
bootstrap code. To get things working properly, we simply need to load
both to memory, then jump to the bootstrap code at 0x3400.
Obviously, because of the way this works, a real MIOS is required.
Léo Lam