Implement a motion provider for Encore (CemuhookUDP, SDL)

[Pixiuchu]

Currently, the only way to use motion controls on the Encore core is with right click (default button). This is incredibly finnicky and, on some games, practically do not work at all due to being buggy on the game's side.

Azahar has a motion configuration which let's you choose the motion provider, between Mouse (Right Click), CemuhookUDP and SDL. I've been using SDL for a year now and it works incredibly well. Since I often use Bizhawk with the game which uses motion controls, such a feature for Bizhawk would be incredibly nice both for casual play and for speedrun/TAS routing. As it is now, it is very difficult to test anything motion-control related.

[CasualPokePlayer]

Motion controls are fairly "special" making them non-trivial to actually expose:

1. If say we're just exposing them as another axis: how do you map these?
   a. Usual axis controls end up mapped when you "move the axis", this wouldn't work well for motion controls (you'd easily end up mapping the controller motions to an unrelated control)
   b. What would even be the range of these motion controls? There isn't really a defined range for motion controls (if say we look at SDL it's just a float, which for an accelerometer specifies it acceleration measured in meters per second squared, and for a gyroscope specifies it as rate of rotation measured in radians per second). Arguably you could just make it the entire floating point range, although since the input system works with integers only we would do the entire signed 32 bit int range as fixed point.
2. If say we're not going to expose them as another axis, but rather "special" controls, then how would that interact with the entire input system? How would we expose that in the UI? How would that work with movies at all?
3. Actually exposing the data would be tricky too, due to how BizHawk polls host input. Host input is polled on a separate thread, and motion controls are more "relative" if anything. How would this be reconciled?
   a. SDL does provide the rate which the motion controls are updated on its side, so in theory that could be used to reconcile it, the point is more that's a nontrivial issue.
4. Even if say we expose it at all, it wouldn't be particularly useful outside of casual usage. Motion controls are not intuitive like analog sticks in how the raw values map to a game. Even TASing user would be extremely confused, they wouldn't get far without just making some lua script do (relatively) complex calculations for them. Already you'd probably need some sync setting to switch between "raw" motion controls and "emulated" motion controls with a mouse, which I would already consider making it so it's forced to "emulated" motion controls for movie purposes (especially if 2 is how it's done, therefore we can skirt around "how do we handle it for movies").

[YoshiRulz]

Frontend: copy Dolphin; backend: copy SDL

[SuuperW]

Already you'd probably need some sync setting to switch between "raw" motion controls and "emulated" motion controls with a mouse, which I would already consider making it so it's forced to "emulated" motion controls for movie purposes (especially if 2 is how it's done, therefore we can skirt around "how do we handle it for movies").

This shouldn't be a sync setting. Rather, any input should be translated to whatever needs to be sent to the core and that is what gets stored in the movie.

[CasualPokePlayer]

This shouldn't be a sync setting. Rather, any input should be translated to whatever needs to be sent to the core and that is what gets stored in the movie.

The sync setting says whether "raw" motion controls (from an actual motion controller) is being used vs. using the "emulated" motion controls with the "tilt" handling (which mind you is core specific and (more importantly) has things which must be put in savestates to work with movies, this kind of conversion is very stateful!). This translation can't be occurring within the frontend, it has to be down to the core level (which means, a sync setting has to be used to determine which should be used).

There is also of course the other point I brought up that raw motion controls (i.e. "acceleration measured in meters per second squared" and "rate of rotation measured in radians per second") are extremely unintuitive for a user to actually use in practice, especially here where you're just giving them a signed int being treated as fixed point. I learned this lesson dealing with the Dolphin BizHawk fork, and even that was slightly more sane as it was only 16 bits large. At least the "tilt" handling is somewhat sane to work with in TAStudio or Virtual Pads.

[CasualPokePlayer]

Frontend: copy Dolphin; backend: copy SDL

The biggest issue I see with this is the fact what Dolphin does with inputs here is very stateful (similarly to the current "tilt" handling, there isn't really a way around this), and to a lesser extent this is core specific (although in theory it could be mostly genericized anyways). This is the kind of thing you're either deciding to put in a ton of variables within the movie file (so think of the 20 different buttons and even the configurable angles/frequencies/etc Dolphin has for motion controls, all of them put into the movie file, plus many different internal variables) or you're deciding to just put in raw motion values (i.e. what Dolphin does, which while probably fine for casual usage or traditional recording, is not fine for TAStudio usage, especially as that implies you're not going to be inputting all those many buttons within TAStudio itself).

If we really wanted to copy Dolphin here, it'd ironically be best off with it handled by the core (probably C# side / genericized like say DiscSystem anyways), the frontend would pick up any of these many motion buttons as just any other button in the core (granted maybe these should be hidden by default within TAStudio) with configurable angles/frequencies/etc just being sync settings (or maybe axes if we want these changable mid-movie), and any internal variables would just be in savestates, and using raw motion controls would be another sync setting which is forced to "don't use" when recording a movie.

[SuuperW]

I have no idea what the best experience would be in TAStudio, or what raw motion values look like, but it would be possible to have TAStudio display buttons + axis values that aren't really in the movie. We just need a way to translate back and forth, which might be difficult if the emulated motion controls are stateful but in a movie we have access to prior inputs so I think it would be doable.