Closed Haris1977 closed 9 years ago
I would suggest you to use a relevant title if you expect some feedback.
It is just a thought:) Thanks petro for changing the title..
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...
@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:
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!
@petrockblog I took the liberty of compiling it and testing it out and I think it is brilliant!
A few notes:
Petrockblog..are u planning on implementing a bug free inputstation module on next future versions of retropie?
@petrockblog sorry for late reply - not had a chance to look at this new code yet - but nice job :)
@petrockblog shame on me to. I compiled but didn't test.
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.
@Haris1977
Petrockblog..are u planning on implementing a bug free inputstation module on next future versions of retropie?
Definitely a "Yes"
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.
@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.
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?
@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.
@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.
@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?
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.
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.
My thought also: controller section inside emulationstation (not only for player1 but for p2,p3 and p4 also!!)
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.
@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.
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!
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.
Those look great! Nice work, love that you used SVG. I'm looking forward to this feature, I think it'll help a lot.
Any thoughts about a 2nd - 3rd or 4th player joypad setup as well?
Generally, the approach that I am following allows for an arbitrary number of configured players. The actual realization depends on each individual system,
I have pushed some updates regarding this issue (see https://github.com/petrockblog/RetroPie-Setup/commit/d654e897b1fd20c549a435fc61f7738106bc234a).
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.
It would be great if we could put this into a next BETA release to have this further tested.
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)
The configuration scripts for mame and pifba still need to be implemented. But this new concept is flexible enough for arbitrary emulator configurations.
@HerbFargus Your great diagrams would look good in the wiki, do you think that you could add them to the controller configuration section?
@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.
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...
@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)
@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:
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...
Those are all really good ideas.
Here is the link for the folder with all of the files:
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.
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...
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.
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 ;)
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
@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).
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:
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 ;-)
thanks. Ill rebuild all the binaries in preparation for a new image and give it a go.
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
Controller configuration is done now, so we can close this issue off. Any imorovements / suggestions for it can be made in new tickets.
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;)