+- 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 - Dark_Slayer - 2015-03-05
Maybe a student could try adding a gaussian blur to the skin framework in a GSOC project instead. I know others would surely be interested in helping. I recall reading Hitcher explain to a WIP skin thread that the only way to currently use blur is just a workaround (and only in windows) where you overlay a blurred snapshot
Certainly mad props to what you guys can do and what's been done to get retro player to where it is
I didn't want to be the first to say it, and there isn't much constructive about piling on as a plus 4 . . . but blur could certainly come later along with other fun stuff like limelight and multi client, right?
RE: Input - edru - 2015-03-05
If you need system icons, feel free to use these I made some time ago:
http://edru.deviantart.com/art/Poor-College-Student-v3-17672994
Got everything in the "retro" area.
RE: Input - garbear - 2015-03-05
(2015-03-05, 01:29)edru Wrote: If you need system icons, feel free to use these I made some time ago:
http://edru.deviantart.com/art/Poor-College-Student-v3-17672994
Got everything in the "retro" area.
nice! do you have png versions of these?
I tried to see how far I could get on blurring yesterday. I created a new kind of group control that renders its children to a PBO in opengl. I'm not sure how to blur the PBO - maybe a shader? - but the PBO rendered just fine. I'm in pretty deep opengl territory now, so I think i'll put the blurring on hold and focus on more higher-level stuff.
Test builds are happening in the imminent future. PR:6227 was merged recently and I've adapted some add-ons to the new system. There were also some bugs from rebasing on 15alpha1, now game video plays but no audio or input.
the current branch is retroplayer-15alpha1 and add-ons are at github.com/kodi-game if anyone wants to try to help with the build system stuff
i'm hoping that 15alpha2 will see the first test builds. thanks for your patience!
RE: Input - Martijn - 2015-03-05
Look what SteamOS went with for input
http://arstechnica.com/gaming/2015/03/steam-controller-steamvr-steam-machines-valves-hardware-push-in-photos/
RE: Input - Adam7288 - 2015-03-05
Yea but SteamOS has a standard controller profile - with retroplayer you are dealing with a different virtual controller for each system...
RE: Input - Adam7288 - 2015-03-05
Sorry about more blur related crap - here is another c implementation
https://code.google.com/p/cairocks/source/browse/trunk/src/gaussian-blur.c?r=31
RE: Input - garbear - 2015-03-06
(2015-03-05, 16:04)Martijn Wrote: Look what SteamOS went with for input
(2014-12-14, 14:26)garbear Wrote:
looks like I got a lot right on my second mockup
unfortunately Adam is right, most of our difficulty is that we're configuring 10-20 virtual controllers, not a single physical one. And we support at least as many skins.This makes most of the features in the SteamOS screenshot quite difficult. See those cute little button icons next to the labels? we have possibly hundreds of buttons to configure. And you saw the extreme difficulties I had to go through to generalize lines across different controllers and skins.
Matrijn: Is there anything specifically you think we should pull from the SteamOS screenshot? with a little creativity I might be able to adapt it to the scope of our project
Speaking of which, it looks like you can control the SteamOS controller configuration GUI with the controller. in my GUI, controller buttons get absorbed by the center picture to highlight buttons as they're pressed. I was thinking of whitelisting A, B and the d-pad so that they can still provide actions inside the controller configuration GUI.
RE: Input - Montellese - 2015-03-06
That SteamOS controller GUI looks odd to me. The lines aren't evenly distributed over the available area and some buttons don't have any lines at all.
But I do like the button icons as they make it much easier to figure out what is meant. But IMO such stuff can still be added later once the basic functionality is working.
RE: Input - da-anda - 2015-03-06
@garbear - IMO this dialog must not block/eat any controller input - there are users only having a controller to navigate through Kodi and you don't know their keymap to whitelist buttons.
RE: Input - Martijn - 2015-03-06
@garbear
just posted the image for comparison/ideas.
I'd love to have retroplayer in in whatever form while we work on the input dialog later
RE: Input - da-anda - 2015-03-06
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
RE: Input - OmniBlade - 2015-03-06
Ideally, you will have default mappings for common controllers on different platforms anyway, so the mapping to the default controller should only be brought up when an unknown device has been connected that kodi thinks is a control pad and prompt the user for buttons needed for basic navigation. Then all other pads should map against the default one.
RE: Input - garbear - 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).
Joysticks show up in the peripherals dialog, so it makes sense that you'd be able to configure each controller from there. We should also probably include a generic keyboard in this dialog so it can be configured too. I think we should *also* have a "Configure game input" action in settings that does exactly this; opens a dialog and prompts for a button or keyboard press, then opens the configuration GUI for that controller.
Alternatively, what if the configuration GUI allowed all controllers to be configured at once? e.g. when prompted for the A button, any controller can press A and that button will be mapped for that controller.
(2015-03-06, 14:03)da-anda Wrote: 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.
I like the idea of a wizard. Can we have both a wizard and free button selection? How would this work?
(2015-03-06, 14:03)da-anda Wrote: 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 posted this video earlier... is this what you had in mind with a window for emulator selection and a separate dialog for mapping?
(2015-03-06, 15:51)OmniBlade Wrote: Ideally, you will have default mappings for common controllers on different platforms anyway, so the mapping to the default controller should only be brought up when an unknown device has been connected that kodi thinks is a control pad and prompt the user for buttons needed for basic navigation. Then all other pads should map against the default one.
My original strategy was to map the virtual 360 controller, then apply heuristics to guess how the other controllers should be mapped. See OP, and try not to vomit. The only advantage is potentially less data to store [with N physical controllers in existence, this is O(N)].
Instead, I want to have the user map every controller individually. This will drastically reduce the complexity. But this is a lot more work for the user. Also, this scales worse [with M emulators, this becomes O(N*M)].
However, I plan to allow users to "vote" for configurations. This means that only 1 user (with a new, unseen controller) has to configure M emulators. After that, the controller's most popular configuration becomes the default, meaning the controller works out of the box for everyone else with no configuration.
RE: Input - da-anda - 2015-03-17
(2015-03-17, 01:03)garbear Wrote:ah yes, something in this direction (with improved UI layout(2015-03-06, 14:03)da-anda Wrote: 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 posted this video earlier... is this what you had in mind with a window for emulator selection and a separate dialog for mapping?
)
RE: Input - ChrisMyhre - 2015-03-17
[/quote]However, I plan to allow users to "vote" for configurations. This means that only 1 user (with a new, unseen controller) has to configure M emulators. After that, the controller's most popular configuration becomes the default, meaning the controller works out of the box for everyone else with no configuration.
[/quote]
Love this idea, seems like the perfect strategy.