Advanced Joypad and Multipeer support

[emufreak]

Multipeer connectivity as we have it now brings Multiplayer gaming to iOS.

I'd like to do the following:

-Enable the mapping of Keys as we have it now for the Onscreen and Physical Controller to Multipeer -Enable The use of Multiple physical game Controllers with iUAE -Enable Individual Keymapping for each connected device -Make the handling as easy as possible

First question is where to handle the settings for Keymapping, on the Client side or on the Server side. I think we have to handle it on the Server side as Physical game Controller are too stupid to handle this.

Secound Question is how to handle this as easy and self explanatory as possible. I suggest the following approach. Whe iUAE is started a small note shows up. If this note is clicked iUAE switches to controller Mode. On the Server side you can add Multiple key Mappings. The Key Mapping works the same as now but there are some new Options. First you can choose to which Amiga Port to connect joystick input. Second you can allow or thisallow connected controllers to use this settings. This way you can make a Keymapping available to the local device only.

Right now i reorganize Joystick classes for this to work:

-First there are classes for MFi, Icade, Onscreen controller. I might add a Parent class if needs arise that handle input -I'll remove as much code as possible and integrate it in Objetive C classes from Lowlevel files to make the code more easily readable -Second there is the Multipeer Connectivity Class. Input (local and remote) is passed tho this class. It'll send the appropriate input to the "amiga" site.

What do you think?

[emufreak]

A few additions: Devices will connect automatically to the next available key mapping. A small message pops up on the server.

Also please inform me if you plan to change anything on Keymapping or Joystick as there is a good chance that we would have merge conflicts.

[MrStargazer]

@emufreak i hope you haven't done any implementation from above yet. I'm currently working on an motion controller for the virtual dpad. So i think it is highly probable that merge conflicts will occur. Can you give me some days to pull my changes?

[emufreak]

I started work already. I merged quiet a lot of changes already. InputControllerView is not affected yet but i plan some changes for this weekend. Did you touch any other Methods? I suggest you make a Pull Request as soon as possible. I will do a lot of work tomorrow still. After that you're good to go for a while. We can then discuss how to get passed each other.

[MrStargazer]

Until now the most changes are in SettingsJoypadVPadController and of course in the Storyboard too. Maybe the conflicts aren't as big as i have imagined. Don't wait for my pull request, since I can't spend too much time for it.

[emufreak]

Thanks. I have a lot of time at the moment and i want to use it for this project. After that it will be long till I have an opportunity like this again. I'm sure we'll make it fit somehow.

[MrStargazer]

I had a look in your new commits and I saw that you are routing MFI through the MPConnectivity? Why not connecting each MFI-Controller directly with the device? Whats the point about routing it via MPC ? Is it maybe because of a only ONE MFI-Controller can be connected to a single device contraint?

[emufreak]

The thought process was like this. We want to share as much code es possible for all classes of device controllers (iCade, MFi, Onscreen, Multipeer) It does make sense to share especially the whole Keymapping stuff between those classes. First thing that sprang in mind was a Parent Class. This is difficult however because some of this classes (Mfi, icade, inputview) are inheriting from Uiview and some not Multipeer.

So I created a kind of Client Server architecture where the Inputclasses are (Mfi, Icade, Input) are the client indepently whether they are called local or remote. They are responsible for handling the buttonstates for each device and sending them to the Server. Multipeer on the other hand handles the Server side of things and is responsible to resolve the Keymapping and communicating with the emulation layer.

This keeps redundant code to a minimum.

[emufreak]

@MrStargazer Planning some changes in the Storyboard. Especially for the View SettingsJoypadController. Do you think you can Merge your changes till the end of the week. It doesn't need to be perfect. Just shouldn't break anything.

[MrStargazer]

@emufreak I'm sure to merge my changes before the end of the week, since i'm pretty close right now. Please wait, because have a lot of changes especially in SettingsJoypadVpadController both Storyboard and Controller.

[emufreak]

Implemented in 1.2. Will close this Issue