Ease controller configuration

[Haris1977]

Many people complain about the difficulty of connecting 2nd, 3rd or 4th controller.

So to keep things clear and in order i would recommend the programmer/rs to use 4 different joyconfig files (eg joyconfig_p1 for player 1, joyconfig_p2 for player 2 etc) in an updated version and not only one. So in order 4someone to connect a 2nd controller he will just run joyconfig_p2 file :)

Of course joyconfig_p2 wont overwrite joyconfig_p1 data in config file

Unfortunatelly I am a linux noob to do it,but can this thought be taken into account??

Thanks;)

[nblondiau]

I would suggest you to use a relevant title if you expect some feedback.

[Haris1977]

It is just a thought:) Thanks petro for changing the title..

[Haris1977]

Let me extend my though about the perfect configuration controller page.

I beleive "Register Retroarch Controller" should be in the first retropie_setup page (e.g option number 8) and not inside SETUP.

Check this link i quickly made myself to take an idea

http://www.2shared.com/photo/nml5LJI4/Final.html

So if anyone wants to register any type of controller he may have (ps3, xbox, usb), he justs goes to number 8 option (left pic).

A new page opens (middle pic). We select which controller we want to register (player 1, 2, etc). Lets choose p 1 (all others should be the same).

An other new page opens (right pic). Here we can choose WHICH TYPE OF controller we do have (e.g ps3, xbox, usb) and by pressing the appropriate option (e.g option number 1) the registration of joyconfig starts as we already know it in option 322 - register retroarch controller).
Especially for option number 2, retropie auto downloads ps3 drivers first and THEN auto register the controller (as if you hit option 321 in retropie 2.3). For option number 3, retropie auto downloads xbox 360 drivers first and THEN auto register the controller (as if you hit option 320 in retropie 2.3). Just as simple !!

Exactly the same procedure is followed for controller number 2, 3 and 4 !:P

I dont have the knowledge to do it but i think this would be straight forward and would keep things clear!

Just a thought...

[petrockblog]

@joolswills @gizmo98 I have just pushed InputStation together with a RetroPie-module "inputstation" for it. I have also adapted the retropiemenu module so that it can be directly called from within ES. InputStation does two things:

1. Running a modified GUI from EmulationStation to capture a controller device and user defined gaming buttons. The list of buttons is inspired from retroarch-joyconfig.
2. After having captured the user defined buttons (these are written into an XML file within the modules directory. It has the same format as es_input.cfg), a bash script executes a list of "configuration scripts" within the input station folder (/opt/retropie/supplementary/inputstation/script/configscripts/). Just as the retropie_packages.sh script expects certain interface functions within the RetroPie modules, the InputStation bash script also expects functions with a certain naming convention. Each emulator can have its own "configuration module". I have started with the configuration modules for EmulationStation and RetroArch. When you have a look into these you will quickly understand the easy interface.

There are probably still some things to enhance, but I think that this might become a very handy tool for a central controller configuration.

Looking forward to your feedback!

[HerbFargus]

@petrockblog I took the liberty of compiling it and testing it out and I think it is brilliant!

A few notes:

• will pressing F4 once you've picked all the buttons that apply to your controller still log what you've put in or do you have to go through the whole process holding down buttons for 4 seconds each to skip to the end? (it might be burdensome for impatient people to have to go through the whole list at 4 seconds each)
• I only have one set of right and left bumper buttons (as I'm sure many do) so I wasn't sure if they pertained to the left and right top or the left and right bottom. Depending on which bumper option applies to controllers with only 2 bumper buttons instead of 4, it might be prudent to place whichever bumper set apply to controllers with one set of bumper buttons first (if it isn't already the first option)
• It might also be useful to have a diagram of the most common controllers and which options pertains to which buttons- I wouldn't mind making one to put on the readme or something.

[Haris1977]

Petrockblog..are u planning on implementing a bug free inputstation module on next future versions of retropie?

[joolswills]

@petrockblog sorry for late reply - not had a chance to look at this new code yet - but nice job :)

[gizmo98]

@petrockblog shame on me to. I compiled but didn't test.

[petrockblog]

No worries. I have also pushed some updates and bug fixes a few minutes ago. I also uploaded RPi 1 & 2 archives for binaries-based installation.

[petrockblog]

@Haris1977

Petrockblog..are u planning on implementing a bug free inputstation module on next future versions of retropie?

Definitely a "Yes"

[petrockblog]

Your opinions: Which emulator(s) should be added next via a configuration script?

When InputStation is stable, I think that it should be called during each boot (only when no es_input.cfg exists) before EmulationStation, so that all configurations have been generated when ES starts. This logic still need to be implemented within the configuration function of the "inputstation" module.

@HerbFargus Good idea with the diagrams! I would be glad if you could come up with a proposal for such diagrams. I have also decreased the time to skip a button to 2.5 s.

[gizmo98]

@petrockblog
Is it possible to add inputstation to emualtionstation as a "plugin/menu item" between config input and scraper options? You could also replace emulation stations input setup with inputstation so there is no confusion about multiple controller setup dialogs anymore.

Recalbox must have something like this. They have forked emulationstation and seem to have added some controller setup stuff for emulators.

[petrockblog]

I agree that a single controller configuration dialog would be the best solution.
Currently, ES does not provide a plugin-in functionality (at least I do not know about it). So, adapting the menu and/or replacing the original input configuration would mean that we have to modify the ES sources and follow a RetroPie-specific fork. Since the development on ES seems to be quite stalled / slow, so that I do not believe that feeding all ES changes upstream would be another option - at least not, if we say that we wait each time, we create pull requests.

We could generate a fork of EmulationStation, add the logic from "InputStation". Then we could create a pull request for EmulationStation and until that request is (eventually) merged, RetroPie could use the RetroPie-fork of ES. Just some thoughts, though.

I am not sure about the best way here. What do you think?

[HerbFargus]

@petrockblog in the coming weeks I'll create a template for the Xbox 360, ps3, and SNES controllers as those seem to be the most common types.

I think calling it on boot is a good idea that will help eliminate much confusion.

I also agree with @gizmo98 that it would be more intuitive to be incorporated as a menu option in emulationstation rather than in the retropie menu.

[gizmo98]

@petrockblog we could ask Aloshi if it is possible to replace the current input dialog with inputstation. He could also tell us how PR validation should take.

(We could also patch emulationstation source code, so the current input setup does not show up anymore...)

Back to topic! I would like to have a mupen64plus config script next.

[petrockblog]

@gizmo98

I would like to have a mupen64plus config script next.

Could you provide a link to some tutorial/description so that I am sure I follow your intended way for configuring mupen64plus in the configuration script?

[gizmo98]

I have something for you. It's already here: https://github.com/petrockblog/RetroPie-Setup/issues/729
We need to add a controller section if the new controller does not already exist.

[McPace]

Sorry if this isn't the place for feedback, but as a new user of RetroPie I just wanted to weigh in.
One controller setup option would be awesome! It's very annoying to have the n64 buttons change based on which video plugin/emulator you are using.

My vote would be to put it under the new retropie menu in ES as that menu is the logical place to go after a user first boots up.

[Haris1977]

My thought also: controller section inside emulationstation (not only for player1 but for p2,p3 and p4 also!!)

[Aloshi]

Some of my thoughts from reading through this thread...

EmulationStation doesn't support plugins, but it's something I looked into. When I originally evaluated the traditional shared library (.dll/.so) plugins, I decided against it because ES's architecture was rapidly changing and it would have just caused breakage constantly (the UI code was changing a lot at the time), requiring plugins to be recompiled alongside ES anyway.

There are a lot of little things that I would be a good for for ES, like an interface for pairing wireless controllers or an interface for connecting to Wi-Fi networks, that are very self-contained that would work well in either a plugin architecture or module architecture. If someone submits a pull request for a simple plugin system that lets plugins register new sub-menus for the main menu, I'd merge it.

Regarding ES pull requests, I quite frankly suck at merging them. There are three that have been sitting in my bookmarks bar for at least a month that say "MERGE THIS" in big, capital letters. I wouldn't be surprised if development looks dead. I did work on adding video support a couple weeks ago though (example that is upside-down for some reason, video frame's source).

If anyone really wants to add controller support to ES directly, I haven't started working on anything, so no worries about duplicate work. I'd like a solution for ES that allows you to configure emulators beyond just input (e.g. set stuff like internal resolution, scaling filters). I just ask that you target the "unstable" branch instead of "master," since it has the new SQL backend which changed a lot of stuff.

Unfortunately, while the bash scripts InputStation uses are easy to write, they won't work on Windows builds of ES, so I can't merge it into the official repo. I've thought about adding Lua to ES for scripting something like this, but I'm fine with anything that would work cross-platform without requiring the user to have a particular shell/interpreter installed.

It would be awesome if there was a stand-alone library (with no GUI) that would convert various emulators' config files to/from a common structure, something like a list of (option_name, option_type, option_value) values. From there a GUI could be built for ES for configuring emulators (or any other front-end). If you make each emulator follow a common option_name scheme, you can even configure multiple emulators simultaneously.

Defining the "option type" gets a bit tricky, since you might want something as simple as a boolean, to a dropdown box of possible options, to a controller input that only accepts button-type joystick inputs from whatever is Player 1's joystick (some emulators have bad joystick and support and, for example, won't support using the 360 controller's analog triggers as buttons) - real validation is tricky.

[HerbFargus]

@petrockblog I've completed the controller diagrams for the SNES, XBOX 360, and PS3. I pulled the same .svgs and colour scheme from the EmulationStation source code so there will be no discrepancies- let me know what you think and if there is anything I need to improve on them.

[petrockblog]

Wow - that looks fantastic!
I plan to work on the integration of the stuff within InputStation into EmulationStation in this week. Do you want to integrate these diagrams into a RetroPie wiki page?

Actually, I must have overlooked those diagrams in ES so far. Where can these be found?

Great work!

[HerbFargus]

I meant to say that I used the .svg symbols from the source code for the dpad up, analog buttons etc. and I just used the same colour codes and fonts as EmulationStation. For the actual gamepads, I just found different svg files that people created online and the I mashed them all together in a program called draw IO through my Google Drive account- everything is vector graphics so it can be scaled as needed.

These are the references to the controller svgs.
http://commons.wikimedia.org/wiki/File:Xbox_Controller.svg

http://commons.wikimedia.org/wiki/File:PlayStation_3_gamepad.svg

http://commons.wikimedia.org/wiki/File:SNES_controller.svg

I have created a wiki page for InputStation (I remixed the ES logo for kicks): https://github.com/petrockblog/RetroPie-Setup/wiki/InputStation

Also as a side note, I was testing out Miroof's node.js virtual gamepad and it has some issues with Inputstation so in the future once you've got Inputstation all figured out for regular gamepads it might be worth looking into implementing virtual gamepads.

[McPace]

Those look great! Nice work, love that you used SVG. I'm looking forward to this feature, I think it'll help a lot.

[Haris1977]

Any thoughts about a 2nd - 3rd or 4th player joypad setup as well?

[petrockblog]

Generally, the approach that I am following allows for an arbitrary number of configured players. The actual realization depends on each individual system,

[petrockblog]

I have pushed some updates regarding this issue (see petrockblog@d654e89).
The enhanced input configuration is now integrated into (a fork of) the unstable branch of EmulationStation. Basically, all input options that joyconfig-retroarch offers, are now also offered in the ES config dialog.
Additionally, one can set a inputAction node in es_input.cfg. Every command within that node is executed via system-call. That is the same way as for all other systems and should be suitable for being integrated into the main branch of ES. RetroPie sets this to sudo /opt/retropie/supplementary/emulationstation/scripts/inputconfiguration.sh.
I have also updated the RetroPie-Setup module for EmulationStation. If you rebuild, install, and configure it, you have everything in place to test this integrated controller configuration. Currently, "only" EmulationStation and RetroArch are configured. The above script inputconfiguration.sh calls all available configuration scripts in /opt/retropie/supplementary/emulationstation/scripts/configscripts/. IF we want to add the automatic configuration of additional emulators, we just need to put the corresponding script into that directory.

[petrockblog]

It would be great if we could put this into a next BETA release to have this further tested.

[Haris1977]

What about mame and fba controls configuration? Will they work too?

(we know that both these emulators need a "special" way for button configuration (e.g tab button for mame and then config+special fba2x.cfg file for fba)

[petrockblog]

The configuration scripts for mame and pifba still need to be implemented. But this new concept is flexible enough for arbitrary emulator configurations.

[petrockblog]

@HerbFargus Your great diagrams would look good in the wiki, do you think that you could add them to the controller configuration section?

[HerbFargus]

@petrockblog They've been moved to controller configuration page on the wiki. https://github.com/petrockblog/RetroPie-Setup/wiki/RetroArch-Configuration unless you feel they are better on their own page as they override the need for retroarch and emulationstation configurations once it's out of beta.

[taalas]

This all looks very promising, well done everyone!

What I have been thinking about for a while is a somewhat similar approach for the documentation (e.g. wiki) in regards to different Libretro cores and their respective mapping to the RetroPad controller. What I had in mind was using the RetroPad controller schematics and creating a diagram for each system (lr-fceumm for example), which shows what buttons from the abstract RetroPad controller are used in this core and what they correspond to in the systems native controller.

If this is something that would help I would gladly create those diagrams in cooperation with @HerbFargus and add them to the respective wiki pages...

[HerbFargus]

@taalas I don't have any problem with your idea- we could add each conceptual retropad controller to each system on the wiki or have an overall retropad page. I think there will be a few discrepancies as some emulators emulate multiple consoles with multiple controllers, and some console controllers are just outright odd (colecovision, etc.) And I would prefer they be in svg format if at all possible so they can be scaled if needed. I can share the files I've already created over Google drive if that would be useful to you (or I could even just add you to the drawings on draw io through Google drive- edits would work the same as a Google doc)

[taalas]

@HerbFargus That sounds excellent. I was definitely planning to do this in vector so we can scale it as needed. For some controllers (like the one's you used) there are quite good SVGs already available, for others I could try to come up with simple schematics for the respective controller. What I think would be benificial:

• Having one page the explains the concept behind having an abstract controller model like the RetroPad (essentially this would be identical to the Libretro Wiki approach), this could also link people to the controller configuration and explain that what they essentially do is mapping their controller to the RetroPad controller.
• Having a schematic for each controller of each core, showing the mapping between the RetroPad and an image of this system's native controller. For Genesis-GX this would need more than one image (RetroPad to Megadrive, RetroPad to Master System, RetroPad to GameGear, etc.)

This would also make people aware of what buttons are available at all for a system (like the Master System having no distinct Start button e.g.)

I would also like to have a RetroPad image that shows the current RetroArch mappings when pressing the toggle button (like toggle+start for exit etc.) I was planning to do this for a couple of friends that I help with their RetroPie's as a hint as to what they can do when pressing "Select" + other button...

[HerbFargus]

Those are all really good ideas.

Here is the link for the folder with all of the files:

https://drive.google.com/folderview?id=0B2TMeZ6iEFvHfmcxQ0o5dkdITlhoME96LWxNSHRlN09QNFlEVXJDUWMwNFAyME1ZOHVBQ1k&usp=sharing

assuming you have a gmail account click on the upper right corner- add to drive

then go to https://www.draw.io/ and select google drive, authorise for your account and you should be able to edit them real time. I will create a diagram file for each console controller in the controller diagrams folder that can be added to/edited as needed.

[taalas]

Thanks @HerbFargus, I will add this to my drive and have a look at the current files. Would it be ok to use a different program from draw.io as long is I produce standard SVG files?

Here is a (very quick) mock up detailing what I had in mind, this would be RetroPad to Libretro-Mupen64Plus mapping:

My first draft had a connection for each pad direction, to reduce line clutter I reverted to a different line start/end symbol and treating the pad directions as a cluster.

Is there any alternative way I can reach you? I never checked if Github supports any kind of direct messaging...

[HerbFargus]

yeah that isn't a problem at all. my email is fargusherb@gmail.com. I'm happy to chat over google hangouts, emails, or whatever. You're welcome to use whatever program you are most comfortable with, I've used illustrator, google draw, draw io, inkscape etc. so I can work with anything you create.

[taalas]

Perfect. I will contact you as soon as I can. Might not have that much time tomorrow but I'd say mid-week should be fine. I have done the N64 controller above in Inkscape since I use it a lot...so that would be my program of choice ;)

[taalas]

Just wanted to follow up on this:

@HerbFargus and I have started a repository where we aim to create original artwork for the RetroPie project. @HerbFargus has already added a couple of the new diagrams to the Wiki. The repository is located at https://github.com/taalas/RetroPie-Artwork

[joolswills]

@petrockblog what needs doing on this for the 3.0 ? I'm a little behind on the status - is everything handled by your fork of emulationstation now, or is inputstation still needed ? Please can you detail where we are - is it safe to build a new emulationstation binary (I am wanting to do an update of the binaries etc and get ready for a new release if your stuff is also ready).

[petrockblog]

Yes, InputStation is not needed anymore - I have just removed the inputstation module. The EmulationStation module now pulls the (temporary) ES fork from me. That fork is based on the more up-to-date unstable branch of ES to make a later merging easier.
I have put two features into that fork:

1. Enhanced input configuration: All buttons (mandatory and optional ones) that can be configured with retroarch-joyconfig can be configured with ES now as well.
2. After the input configuration dialog is finished by the user an optional hook is called that is configured in es_config.cfg. The emulationstation module configures this hook with a RetroPie specific script that, in turn, calls all config scripts with a specific interface within a certain folder. These config scripts map the ES input configurations to the emulator-sepcific configurations.

It is safe to build a new emulation station binary! I am not aware of any bugs on the ES binary. There is still work to do to support the automatic configuration of more systems: Currently, only EmulationStation itself and RetroArch are supported. I already thought about a call for voluntaries via Twitter ;-)

[joolswills]

thanks. Ill rebuild all the binaries in preparation for a new image and give it a go.

[urtzai]

Hi guys I read this thread and I wonder if this new build will provide support for Ipega PG-9025... Maybe is a dumb question and I don't wanna bother you but last few days I've been trying to configure in a Retropie 2.6 version with no succeed...

I also posted a question here: http://stackoverflow.com/questions/30481198/using-ipega-bluetooth-gamepad-with-retropie

Thanks all, really good job

[joolswills]

Controller configuration is done now, so we can close this issue off. Any imorovements / suggestions for it can be made in new tickets.