+- 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 - da-anda - 2015-02-23
I like the lines - way better then showing the "name"/label of a button along with some mapped action. I'd at least avoid having too many text on screen - less is better IMO and with the lines you directly see which button does what - even if you have no idea what button "R2" is. So I like you screenshot above pretty much garbear, but I wouldn't show the button labels if no action is mapped yet - simply state that it's unmapped/undefined. I know this doesn't answer if the lines need to be dynamically generated or not. IMO it's no necessity (at least not for a first version) but would ofc be a nice thing to have. Maybe these could be handled via our GUILib in general - so adding some graph/plot features to it that skins could make use of also in other parts of the UI.
RE: Input - Adam7288 - 2015-02-23
Instead of lines, why not simply have a picture of the controller on the left, and a table of mapping on the right. When you cycle through each field to map the buttons, the corresponding area on the controller diagram is shown, with the rest of the controller getting the Gaussian blur treatment - this can be achieved simply by using an image mask.
RE: Input - Woerd88 - 2015-02-23
+1 for the idea with a list of available buttons/mapping and highlighting this on the shown controller when the button is selected in the list.
This could also work with some kind of wizard that the user has to map all the buttons in the first run:
Press the button for SNES A
(Controller is grayed out a little, and the A button on the SNES controller is highlighted)
Press the button for SNES B
(Controller is grayed out a little, and the B button on the SNES controller is highlighted)
Cool discussion btw
RE: Input - OurJermain - 2015-02-23
Maybe this could be used to change the hotkeys on a hdmi cec tv remote.
RE: Input - garbear - 2015-02-23
(2015-02-23, 01:08)Adam7288 Wrote: I don't think there is a right or wrong way to do this. Here is another solution to the issue which I was really impressed by (openemu)
(2015-02-23, 17:40)Adam7288 Wrote: Instead of lines, why not simply have a picture of the controller on the left, and a table of mapping on the right. When you cycle through each field to map the buttons, the corresponding area on the controller diagram is shown, with the rest of the controller getting the Gaussian blur treatment - this can be achieved simply by using an image mask.
This simplifies things greatly. Removes awkward navigation between the far left and right sides of the screen. I think gaussian blurring would look better than dimming. Maybe for v2 we can offer skins the choice of which focusing method.
I also think it'd be cool to zoom in on the button as a focus method instead of blurring. that would require a high-resolution controller image though.
(2015-02-23, 11:53)Dark_Slayer Wrote:
Another good idea, but controller buttons aren't laid out in a neat little grid and navigating uneven layouts is awkward with a remote.
(2015-02-23, 12:48)da-anda Wrote: Maybe these could be handled via our GUILib in general - so adding some graph/plot features to it that skins could make use of also in other parts of the UI.
I'm pretty set on Adam7288's idea of a single list of labels and applying focusing effects to the image. That said, can you think of any other applications of lines in the GUI? It wouldn't be hard to translate my python code to c++ and create a generic API that accepts a costmap, start and end goals and returns the coordinates for the optimal paths.
(2015-02-23, 20:58)OurJermain Wrote: Maybe this could be used to change the hotkeys on a hdmi cec tv remote.
I've been struggling with this. Because Kodi already has a way to change hotkeys. And it's not end-user friendly. unfortunately that inflates the scope of this project, so I think i'll have to stick exclusively with controller-to-controller mapping.
RE: Input - da-anda - 2015-02-24
(2015-02-23, 23:22)garbear Wrote:If you manage to get a blur filter to our GUI engine I immediately stop talking about the line approach and jump on the blur train(2015-02-23, 17:40)Adam7288 Wrote: Instead of lines, why not simply have a picture of the controller on the left, and a table of mapping on the right. When you cycle through each field to map the buttons, the corresponding area on the controller diagram is shown, with the rest of the controller getting the Gaussian blur treatment - this can be achieved simply by using an image mask.This simplifies things greatly. Removes awkward navigation between the far left and right sides of the screen. I think gaussian blurring would look better than dimming. Maybe for v2 we can offer skins the choice of which focusing method.
A blur filter in GUI engine would open up sooo many cool new skin features. But I guess the blur would be a python only thing again like the lines? Rebuilding it using our GUI engine would be kickass though (so masking images/planes with a random shap and apply effects and animations on it etc).(2015-02-23, 23:22)garbear Wrote:Have you seen the setup wizard of the Alienware Alpha where they have these 4 dots (reflecting the 4 wizard steps) connected by lines and while the user moves forward to the next step the dots change their position while staying connected? Seeing that made me think of a nice skin with elements that move on interaction connected by lines. Or some HUD like interface where on click a connection-line is moving and expanding to a info container. Ah well - I guess my imagination is going a bit too far on this(2015-02-23, 12:48)da-anda Wrote: Maybe these could be handled via our GUILib in general - so adding some graph/plot features to it that skins could make use of also in other parts of the UI.
I'm pretty set on Adam7288's idea of a single list of labels and applying focusing effects to the image. That said, can you think of any other applications of lines in the GUI? It wouldn't be hard to translate my python code to c++ and create a generic API that accepts a costmap, start and end goals and returns the coordinates for the optimal paths.
So as mentioned above - it's not really necessary to be dynamic or be done via GUIlib - it would just be a bonus.Just a thought - but could the lines be generated dynamically ONCE for each controller and skin and from then on simply use the cached/generated route? That way only opening the dialog for the first time would be slow.
RE: Input - Adam7288 - 2015-02-24
Here is something that may save some time implementing the blur in c++:
http://blog.ivank.net/fastest-gaussian-blur.html
RE: Input - garbear - 2015-02-24
(2015-02-24, 12:44)da-anda Wrote: Just a thought - but could the lines be generated dynamically ONCE for each controller and skin and from then on simply use the cached/generated route? That way only opening the dialog for the first time would be slow.
Caching would OFC be mandatory, the search algorithm can be quite costly on certain worst-cases, especially when there's no solution. My thought was to do EVERYTHING offline in Python, because then speed isn't an issue and honestly, this kind of stuff usually requires hand-tuning to get an acceptable collection of paths.
there's some pretty powerful search algorithms out there though, so a native GUIlib implementation isn't that far-fetched. I'd sure like the challenge!
(2015-02-24, 20:38)Adam7288 Wrote: Here is something that may save some time implementing the blur in c++:
http://blog.ivank.net/fastest-gaussian-blur.html
thanks for the link adam! i'm sure we'll need to roll our own gaussian blur because we'll need the blur to be nonuniform (i.e. no blur over the highlighted button) and a blurring animation would be nice.
RE: Input - Dark_Slayer - 2015-02-25
(2015-02-24, 12:44)da-anda Wrote: If you manage to get a blur filter to our GUI engine I immediately stop talking about the line approach and jump on the blur train
(2015-02-24, 20:38)Adam7288 Wrote: Here is something that may save some time implementing the blur in c++:
http://blog.ivank.net/fastest-gaussian-blur.html
I thought I recalled blur not being possible yet http://forum.kodi.tv/showthread.php?tid=192909&pid=1689111#pid1689111
http://forum.kodi.tv/showthread.php?tid=140884 Obviously you both already knew that, but I agree building it in would be nice
I agree cycling a non-grid layout can be confusing, the lines are a great solution to simplify that
RE: Input - garbear - 2015-02-25
playing games in Kodi isn't possible either, but that's never stopped me
i started coding the configuration GUI. chances are I'll implement blurring and dimming (and brightening for Alaska). I would also really like to try my hand at single-line-drawing, just to compare the different methods side-by-side.
RE: Input - Dark_Slayer - 2015-02-25
(2015-02-25, 06:04)garbear Wrote: playing games in Kodi isn't possible either, but that's never stopped me
touche
RE: Input - da-anda - 2015-02-25
@garbear - will you be using shaders for the blur and dimming etc?
RE: Input - garbear - 2015-02-27
the important thing is to get SIMD speedups. i've never used shaders before, so i'll probably start by pulling in OpenCV or Eigen or hand-rolling a slow shitty approximation. don't worry, everything will be behind a sane API so these different strategies can be swapped out depending on performance/aesthetic desires.
RE: Input - garbear - 2015-02-28
ok, i've hammered out a basic concept of the controller configuration gui
RE: Input - Woerd88 - 2015-02-28
Nice! Looks very clean!