This is done by:
1) Implementing said protocol in a new controller input class CemuHookUDPServer.
2) Adding functionality in the WiimoteEmu class for pushing that motion input to the emulated Wiimote and MotionPlus.
3) Suitably modifying the UI for configuring an Emulated Wii Remote.
Makes our libraries explicitly link in which libraries they need.
This makes our dependencies explicit and removes the reliance on the
LIBS variable to contain the libraries that they need.
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.
Better separation of concerns. Relegates `ControllerInterface` to
enumerating input controls, and the new `ControlReference` deals with
combining inputs and configuration expression parsing.
ControllerEmu is a massive class with a lot of nested public classes.
The only reason these are nested is because the outer class acts as a
namespace. There's no reason to keep these classes nested just for that.
Keeping these classes nested makes it impossible to forward declare them, which leads to quite a few includes in other headers, making compilation take
longer.
This moves the source files to their own directory so classes can be
separated as necessary to their own source files, and be namespaced under the
ControllerEmu namespace.
No way to properly enable it from an end user perspective yet.
Doesn't require root.
This same sort of system can be used for the Dolphinbar in the future for real wiimote support.
Currently only works on unix, but can be extended to other systems. Can
also be extended to do wiimotes.
Searches the Pipes folder for readable named pipes and creates a dolphin
input device out of them. Send controller inputs to the game by writing
to the file. Commands are described in Pipes.h.
It substantially complicates the code and doesn't really provide any
functionality. According to the forums, the Android app is out of date
and has been broken for quite a while.
If we want to add this back, I'd write an app that speaks a more native
Wiimote protocol, and we can hook that up to the backend quite easily.
It could even be over our NetPlay protocol!
This contains a new, hand-written expression parser to replace the old
hack language based on string munging. The new approach is a simple
AST-based evaluation approach, instead of the "list of operations"
infix-based hack that there was before.
The new language for configuration has support for parentheses, and
counts "!" as a unary operator instead of the binary "NOT OR" operator
it was before. A simple example:
(X & Y) | !B
Explicit device references, and complex device names ("Right Y+") are
handled with backticks and colons:
(`SDL/0/6 axis joystick:Right X+` & `DInput/0/Keyboard Mouse:A`)
The basic editor UI that inserts tokens has not been updated to reflect
the new language.
