This is an extension of host input authority that allows switching the
host (who has zero latency) on the fly, at the further expense of
everyone else's latency. This is useful for turn-based games where the
latency of players not on their turn doesn't matter.
To become the so-called golfer, the player simply presses a hotkey.
When the host is the golfer, latency is identical to normal host input
authority.
This is only ever used internally. Also change the std::string name over
to a const char*, so that we don't need to potentially allocate anything
on the heap at immediate runtime.
Previously, a total of 114 std::string instances would need to construct
(allocating on the heap for larger strings that can't be stored with
small string optimizations). We can just use an array of const char*
strings instead, which allows us to avoid this.
Some button names should be translated, for instance Up, Left and such.
At the same time, some other button names shouldn't be translated,
for reasons that might be less obvious. In 0146456af, I removed the
_trans markers for button names that never need to be translated
(such as A and B), but that isn't actually enough to ensure that
DolphinWX won't try to translate them anyway. This commit adds a bool
that explicitly tells the GUI whether a button name should be translated.
Otherwise we'll have problems like the GUI treating the button name "B"
(which isn't supposed to be translated) as matching the translatable
string "B" (being an abbreviation of "bytes"), meaning that the button
"B" will be labeled "o" when running Dolphin in French (after
translations get pulled from Transifex the next time).
By the way, while it turned out that DolphinWX translated all button
names, it also turned out that DolphinQt2 translated *no* button names.
Go figure. This commit makes them consistent with each other.
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.
Making changes to ConfigManager.h has always been a pain, because
it means rebuilding half of Dolphin, since a lot of files depend on
and include this header.
However, it turns out some includes are unnecessary. This commit
removes ConfigManager includes from files which don't contain
SConfig or GPUDeterminismMode or GPU_DETERMINISM (which means the
ConfigManager include is not used).
(I've also had to get rid of some indirect includes.)
For hotkeys, changed HotkeyManager to allow to get and make partial groups of hotkeys.
Also preserved the old configuration naming scheme for the ini, this is done to preserve compatibility with the older groups structure.
Add the ability to get GCPad control groups
Used like the HotkeyManager methods, this is used for the new GCPad configuration dialog.
Add the ability to get groups of Keyboard input
Same reasons as the previous ones.
Add ability to get groups of Wiimote input
Add the ability to get extensions group
This needed to pass to 3 classes. Will be used for their respective dialogs.
The usage of "Wii Remote" and "Wiimote" in the interface is inconsistent. "Wiimote" is also not a real word nor is it an official product name. Therefore I have changed instances of "Wiimote" in the UI to instead say "Wii Remote". I also made a couple of minor grammatical changes as well.
This is mostly a resubmission of #4338 but there are some minor other changes as well.
Currently, `g_controller_interface` is initialized and shut down by each
of `GCKeyboard`, `GCPad`, `Wiimote`, and `HotkeyManager`.
This 1) is weird conceptually, because it necessitates passing a pointer
to the native window to each of those classes, which don't need it, and
2) can cause issues when controller backends are initialized or shutdown
multiple times in succession.
This adds the ability to passthrough a whole Bluetooth adapter and skip
the majority of the Bluetooth emulation code. We use libusb to send HCI
commands, receive HCI events and transfer ACL data directly to the
first adapter that is found or to a specific adapter (if configured to)
This is possible because the Wii's Bluetooth module is actually just
a pretty standard Bluetooth adapter…
…except for two vendor-specific commands, for which replies are faked,
and also for the sync button. This adds a hotkey that works in the
exact same way as the sync button would on a Wii: it triggers an HCI
event, which emulated software interpret as a command to perform
a BT inquiry.
This commit also changes the UI code to expose passthrough mode
and WII_IPC_HLE to be a bit more thread safe (for the device map).
This adds RemoveDevice() to ControllerInterface, fixes ExpressionParser
and some other code to support device removals without crashing,
and adds an IsValid() method to Device, to prepare for hotplugging.
This adds RegisterHotplugCallback() to register a callback which will
be invoked by the input backends' hotplug threads when there is a new
device, so that Core (GCKeyboard, GCPad, Wiimote, Hotkey) can reload
the configuration without adding a dependency to Core from InputCommon.
The Setting class was used for both numeric values and booleans, and
other parts of the code had hacks to make it work with booleans.
By splitting Setting into NumericSetting and BooleanSetting, it is
clear which settings are numeric, and which are boolean, so there is
no need to guess by checking the default values or anything like that.
Also, booleans are stored as booleans in config files, instead of 1.0.
Techjar