+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+---- Forum: RetroPlayer Development (https://forum.kodi.tv/forumdisplay.php?fid=194)
+---- Thread: Input (/showthread.php?tid=211138)
RE: Input - OmniBlade - 2015-03-17
I must confess, I prefer the RetroArch system of mapping one controller and then you get reasonable sane defaults for all emulators right off the bat and only need to tweak individuals ones that don't suit you. I assume there will be a database that Kodi will query then for the controllers it has seen and how they map to the various emulated controllers based on the "approved" configuration?
RE: Input - jjd-uk - 2015-03-17
(2015-03-06, 14:03)da-anda Wrote: I gave http://www.recalbox.com/ a quick try on my PI2 today. They also have a button mapping feature which we could adopt. What they do is that you open up a mapping dialog where they ask you to press any button of the controller you'd like to use for mapping for 4 seconds (device identification). After that they switch to a mapping window that's trapping ALL input from the according device and is running through an automated step by step mapping wizard. So they show a list of let's say 10 buttons and ask you one after another to press the button you'd like to map this function/virtual key to. We could do the very same, but in addition to the button labels we also highlight the related button of the virtual controller. So only trap controller input when in active mapping mode. The identification of the physical controller/device to be mapped by pressing any button of a connected device (could have also been keyboard I suppose) for X seconds is a really nice idea as well. Like when you have a XBOX and PS4 controller connected and like to map both individually.
doing it in a simmilar way would also allow us to split up the windows for game/emulator selection and the mapping window which is showing the virtual controller. So in the screenshots of current version the horizontal menu would not be there but in a separate "overview/selection" window
I was intrigued by this and found this video which shows it well
https://youtu.be/pcCCTdS_P4U?t=11m
Screens are in English but the commentary is in French I think, so no idea what he is saying.
RE: Input - garbear - 2015-03-17
(2015-03-17, 14:21)OmniBlade Wrote: I must confess, I prefer the RetroArch system of mapping one controller and then you get reasonable sane defaults for all emulators right off the bat and only need to tweak individuals ones that don't suit you. [emphasis added]
You're aware that RetroArch and RetroPlayer use the same cores, the same API? If I give up and do nothing, this strategy is already built into the libretro API.
...Almost.
Consider the first half: mapping one controller and then you get reasonable sane defaults for all emulators right off the bat. This is built into the libretro API. The API contains the following controller abstraction: The RetroPad is essentially a Super Nintendo controller, but with additional L2/R2/L3/R3 buttons, similar to a PS1 DualShock. But OFC, you can't map every controller to every console without some edge cases.
Hence the need to tweak individuals ones that don't suit you. Problem solved. However, tweaking emu configs is NOT part of the libretro API. This is implemented in their frontend, RetroArch.
So you see, RetroArch's system bleeds between the API and the implementation.
I have managed to build an API that contains both the "reasonable sane defaults" AND the "tweaking" part.
(2015-03-17, 14:21)OmniBlade Wrote: I assume there will be a database that Kodi will query then for the controllers it has seen and how they map to the various emulated controllers based on the "approved" configuration?
Here's the power of my expanded API: the "tweaking" can now be used as feedback for the "reasonable sane defaults" part. In the interest of time, my April 1 test builds will copy your preferred system exactly. Eventually, though, collected data can be leveraged to evolve "reasonable and sane" into "optimal". Thus, over time, the need to tweak individuals ones will converge to a minimum. IMO less configuration == improved UX.
Building this database you propose, where Kodi can query for controller configurations, is a large effort. My "feedback" idea is a tiny rain drop in this huge bucket. IMO, as long as we're putting effort into building this database, we might as well include this small optimization.
RE: Input - ghutch92 - 2015-03-18
I know that this thread has been mostly about controller input, but has there been any thoughts about mouse input for gun games or trackball games using the mame core? Specifically multiple mice input.
RE: Input - garbear - 2015-03-18
yes all are included in the api
RE: Input - OmniBlade - 2015-03-19
That has clarified a lot for me, my impression was that every emulator core would need a separate config defining before it was even usable if it didn't have one in the db already.
I have nothing against the trickling in of configs as people create them and a "survival of the fittest" type system to get the "optimum" sounds great in theory. How do you plan to handle cases where the mapping isn't straight forward such as with the N64. PS3 style layouts can be mapped with either the L trigger or L button mapped to L and Z depending on if the game you are playing was designed for dpad or analog. Depending on what the users are playing this might create a sub optimal layout for some use cases. This seems to come up semi-regularly on the RetroArch forums. An A and B config that you could attach to different games in the library after first play would probably be desirable in this situation. The MegaDrive/Genesis suffers a similar situation with the 3 and 6 button pads.
RE: Input - garbear - 2015-03-20
The idea is to have this decision be data-driven. That's why I really want to implement the "voting" idea.
Who knows? maybe the data will be clustered around two layouts. If the graph looks like this
Code:
.
. __ __
. / \ / \
. | | | |
.___/ \______/ \_____Then maybe we create a wizard that offers these two choices initially and 99% of users will be satisfied.
RE: Input - natethomas - 2015-03-20
(2015-03-20, 02:23)garbear Wrote:Code:.
. __ __
. / \ / \
. | | | |
.___/ \______/ \_____
We can call it the Two Penis layout.
RE: Input - garbear - 2015-04-11
update on input - it works!
still some work left before it's really usable... there's no default keymaps, and saving keymaps isn't implemented, so controls have to be configured every time Kodi starts. but it's a start
libretro supports the ability to choose which device is plugged into each port. i was thinking of doing an icon-based selection dialog like this
unfortunately i probably won't have time for this for a while, but it's never too early to start brainstorming
RE: Input - Nezza - 2015-04-12
Looks great. can't wait!
RE: Input - Adam7288 - 2015-04-12
Thank you for your efforts as always.
RE: Input - CharlieMopps - 2015-04-12
I notice you have a lightgun in there. I thought there was no way to do lightguns on LCD?
RE: Input - OmniBlade - 2015-04-12
There are solutions such as the Wiimote or similar devices that use IR points of reference to determine what you are pointing at. Most emulators also let you use the mouse to point with as well.
RE: Input - CharlieMopps - 2015-04-13
(2015-04-12, 19:28)OmniBlade Wrote: There are solutions such as the Wiimote or similar devices that use IR points of reference to determine what you are pointing at. Most emulators also let you use the mouse to point with as well.
The wiimote thing is supposedly awful from what I've read. And a mouse on a media pc? I hope lightgun support is low on the priority list. :-)
RE: Input - Leuthil - 2015-04-13
An icon based solution is cool and I think it's very intuitive. I'm wondering about future controllers though. The list of supported gamepads with icons will have to be kept up to date forever which I guess is not necessarily a bad thing. There could be a generic gamepad icon used if it's unknown.