Input Abstraction + Custom Button Mapping

[Emerald-Wolf]

There are already tickets for different features involving input such as custom mapping (#56) for combinations to generate a different input value, but the common response is that a more general solution is needed. By removing the actual button mapping and controller support from the cores and creating layers to handle user input and converting it into the expected input for the cores more features and controller types will be easier to add now and in the future.

This proposal includes custom button mapping since it will already be doing button mapping and the only additional step would be handling file selection from the available map files uploaded. The ability for the application to generate these custom map files can be added during or after implementation.

The following pieces and steps are needed as the basics to accomplish basic button mapping:

1. A loader to read the map from a file and initialize or update item 2.
2. A thread to receive user input and compare it to the defined map for the current core and store information in item 3.
3. A structure to hold current input states and bridge the input thread and the active core. (Should probably be designed to bridge Swift and Objective-C and further discussion is required on should it be within the input thread, the core, or mirrored between the two.)
4. Replacing current core button code with code to receive, hold, and process the structure that is item 3.

Additional Considerations: General:

• The methods, structure, and classes should probably be created in such a way that they can be treated more as plugins allowing substitution of one for another such as using MFi or iCade instead of the on screen buttons when available.
• The ability to have mixed input such as a MFi controller with on screen buttons if a controller map requires more buttons then available.

Item 1:

• The button map should be stored in a dictionary format using inputs received as the key to allow the mapped button to be looked up quickly.
• Map file structure storage should probably be a file per configuration to allow users to extract and share custom configurations and data can be stored as a json, or similarly structured, file to allow it to be human readable and easy to read the data in.
• Map file naming and extension need to be defined. Example PSXConfig Name.map could be used the part before the defines the system and everything else before the .map is the user defined name, or use a longer extension and define the system there such as .psxmap.
• Creating default button mapping files for iCade, MFi, and on screen buttons.
• A simple UI to select a custom map file that is compatible with the current core.

Item 2:

• On screen buttons should probably be handled as part of this thread since it will be responsible for dealing with the input received.
• Some input may generate events not meant to be passed on such as MFi controllers menu button being used to open the menu. This will be the groundwork for anyone wanting to add additional functionality to controller buttons.
• The ability to swap controller maps during core execution from the menu.

Items 3 & 4:

• This is meant to act in a way that is similar to how input is handled now, but if multiple cores use the current input method as more of a tacked on structure to just get things to work then alternatives such as passing translated events directly to the core can be investigated.
• Multiple methods of passing information are likely to be needed so trying to force a single method on all the cores should be avoided.
• How information is passed to the cores should be treated as something to be optimized and refined since it may simplify how input is handled by the core.
• Determine if an event stack/que might be the structure best suited to handle bridging input and the core. (Might prevent issues with missing when the core polls the input states.) Examples PSX_Button_X_Pressed, PSX_Button_X_Released, PSX_LAnalog_X_NewValue = 0.5
• The structure may be as simple as a set of arrays containing which digital buttons are pressed and the current values for the analog inputs. But each core may have a different style that will work best.
• Determine maximum number of inputs and the type each is such as digital or analog, and create naming scheme to use. Examples PSX_Button_X, PSX_DPad1_UP, PSX_LAnalog_X

Possible improvements after implementation:

• UI for generating custom configurations by allowing user to select the desired input then clicking a button on the controller to map it to.
• Custom button combinations or behaviors. Examples press MFi menu button for start, hold for menu, or use as a modifier key if another button is pressed while holding.
• Additional input types such as keyboard or Arduino as discussed in on there topics.
• Investigating possible use of CoreBluetooth to try and sync controllers such as duelshook 4, xbox wireless controllers, and joy cons.
• The ability for cores to pass back data such as rumble for the haptic engine or controller to use.
• Additional data types that may be passed to cores such as microphone, gyroscope, accelerometer, and touch input for future cores.

[JoeMatt]

So I already devised a way to to this auto-magically, at least the linking of buttons on a controller, to a core. It's maybe a bit complicated at first because it uses Swift 4 key paths, generic protocols, protocol default implementation extensions and such. It's basically a protocol oriented design, but by doing it this way, a Core just has to have an extension in a .swift extension (can still be an ObjC defined class). It only has to declare it uses the MappableCore protocol, define an enum or struct that fire the required type alias, and implement 1 method, which is what do to with the data. It's based on polling GCController's since most cores wouldn't notice a difference between that an async button events since they run on a cycle timed run loop internally (though I suppose it could be extended for event callbacks too)

This is a Proof of Concept code, it compiles but there are issues, namely I didn't get far enough in KeyPath generalising to make it work with various controller types, since GCGamePad and GCExtendedGamePad annoyingly don't share a root class, but you can use all sorts of other protocol things to make it look like they do, or just make MappableCore a generalised protocol and make default extensions for 3 built in controller classes. Or use a middle class that is generalised and just pass the class type of the controller when the core is running. Either way, I'm pretty sure I can get all that to work.

Not worried about the Swift requirement, I have a branch where almost everything used here is already converted to Swift 4 or really close. That's why I was putting this feature off. They whole thing is done easier with swift enums and protocols You can see my N64+Swift branch in this repo for the progress so far. There was already a plan for Cores to expose their configuration data in their own .plist in their framework and the class to use to initialise them like .bundles of code do on OS X so that the main app can be agnostic of what caores it's built with, Open EMU is built this way. Provenance was started before .frameworks on iOS so evetyihng was static libs and a global plist.

It seems complex but it's a write once type of solution, instead of each core having to know how to read config settings for each possible controller type which is how it's done now, but with hard coded mappings. We have at least over a dozen cores each with card coded mappings for 3 controller class types, not to mention iCade.

I have an extreme headache and eye strain so I just glanced at your proposal. But I'm just sharing my work so far,

https://gist.github.com/JoeMatt/48f2640f87aae6c48b9854c67da18934

[Emerald-Wolf]

That definitely looks like the start of a way to do it.

You're comments in the code seem to indicate that the keypaths are a hinderance to generalizing the code for MFi controllers. Would it be easier to just use strings to indicate which buttons the core wants to use as defaults and then work the other direction by finding out which controller profile is connected then cycling through the supplied list and make the actual connections that are available?

If the number of controller mappings is so high it might be easier to just try and make a loop on another thread, if necessary a different loop could be loaded per core, where controllers can register a listener for events such as the valueChangedHandler used by the GCGamepad/GCExtendedGamepad and tie those to the functions created for use by the on screen buttons such as are found in the files like:

Provenance/Controller/PVPSXControllerViewController.m

You wouldn't get instant compatibility with all cores for all controller types, but it sounds like there might not be a magic solution for the iCade any way so might it be easier to do?

[JoeMatt]

Yeah since key paths might be a pain in the ass, you can do something really similar where I made an extension to the controller classes to expose an array of keypaths, instead make an array with enums, the enums containing an input type like, switch/button/pressure button/axis, and an associated value that's a tuple or struct of conguration info about that input on that controller. You could even store a function that is used to grab the value like (void)(float) { return self.buttonA.value }. KeyPaths are nearly the same thing as using a function like that.