[apanloco]

[*]Peripheral add-on samples the driver's state and emits events for button, hat and axis changes

A quick question: The sampling of state you mention sounds like polling. My experience tells me polling joystick state have a tendency to miss events, especially under heavy load. (I.e. you manage to both press and release in between polls). Just wanted to shine in with some joystick event experience

[garbear]

I'm polling once per frame, so quick presses (< 16ms) or glitchy behavior could get skipped. If this becomes a problem i'll just add a dedicated polling thread and poll more frequently or block on the file descriptor. polling happens in the add-on, so we can fix this via an update even after Kodi ships.

thanks for the heads up

[Powerhouse]

I have been keeping my eye on these pages, and can't wait for these game features to be released in Kodi. But until that time, might I make a suggestion.

I know you are working your ass off making all the Joystick changes, which is great, but could you also get a default profile for said Joysticks so they are already assigned the correct values within the various game systems.

For Example...

I found a Config file for MAME, that enables both the XArcade Tankstick, and\or up to 4 XBOX 360 controllers to work with all MAME games. This file also has extra functions like allowing MAME racing games to use the Triggers for the Gas and Breaks, using both Analog sticks to work in games like Robotron, etc. So instead of having thousands of Config files (one for each game), this one Config file does it all, for every MAME game.

You can check out the following youtube video regarding this Config file working in Hyperspin.
https://www.youtube.com/watch?v=5pB1b595Q_g
or read about the Config file here...
http://forum.arcadecontrols.com/index.ph...c=100079.0

Basically what I am asking, is that there should be a default Joystick config file for every game system, that allows the maximum amount of Joysticks (some game systems only have a Single Joystick, or just Two), that is already pre-configured to work, once you plug a Joystick into the system to play. You could still go into the game and change things around if you didn't like the Config, but by having a default Config present, this allows everyone to instantly go into a game and start playing, with no messing around with a game Config first (and for every Joystick in multi-player games).

[garbear]

I had some fun hacking on the configuration GUI today



Specifically, I tried to see if I could automatically generate the lines connecting the buttons to their labels.

I created a new kind of add-on, "Game Peripherals", to provide pictures and metadata for the various game console controllers we support. Each game peripheral contains a layout that will be shown in the GUI:



I loaded this image in GIMP and extracted the coordinates for the buttons. I placed these coords in the addon.xml file:
 

Code:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon id="game.controller.nes"
        name="NES Controller"
        version="1.0.0"
        provider-name="garbear">
    <requires>
        <import addon="xbmc.game" version="1.0.0"/>
    </requires>
    <extension point="xbmc.game.peripheral" name="NES Controller">
        <layout image="layout.png" overlay="overlay.png" costmap="button-costmap.png" width="558" height="262">
          <button label="30000" geometry="circle" x="466" y="164" radius="25"/>
          <button label="30001" geometry="circle" x="400" y="164" radius="25"/>
          <button label="30002" geometry="rectangle" x1="287" y1="175" x2="335" y2="189"/>
          <button label="30003" geometry="rectangle" x1="223" y1="175" x2="271" y2="189"/>
          <dpad label="30004">
            <button label="30005" geometry="rectangle" x1="101" y1="92" x2="141" y2="128"/>
            <button label="30006" geometry="rectangle" x1="139" y1="126" x2="172" y2="162"/>
            <button label="30007" geometry="rectangle" x1="101" y1="160" x2="141" y2="194"/>
            <button label="30008" geometry="rectangle" x1="70" y1="126" x2="103" y2="162"/>
          </dpad>
        </layout>
    </extension>
    <extension point="xbmc.addon.metadata">
        <summary>NES Controller</summary>
        <description>The game controller used for both the NES and the Famicom features a simple four button layout and a cross-shaped joypad.</description>
        <disclaimer></disclaimer>
        <platform>all</platform>
        <nofanart>true</nofanart>
    </extension>
</addon>

I wrote a python script that generates a "cost map", where pixel brightness corresponds to the cost of drawing a line through that pixel. I used openCV to render the buttons as they are given in addon.xml, and then dilated the image with an increasing number of iterations to make the cost "fan out" from the buttons.



The best path from button to label should have a few constraints:

• Contact between line and button should be perpendicular
  
• At most 1 vertical segment, and (subject to being perpendicular) only if line starts on button top or bottom
  
• At most 2 horizontal segments, at most 2 diagonal segments
  

The path finder is straight-forward A* search under the constraints above. Initial tests are promising:



A* in python is too slow to run in realtime, so I'll probably generate these paths offline and include them in a resources/ folder. This way, we can generate an array of paths that skins can select from, depending on where they wish to place the button labels.

[Mettbrot]

If you generate them offline and store them anyway istn't this a bit of over engineering? I don't know how many controllers there are but if you have to set up a mask for each anyway you might as well choose the paths manually
Don't get me wrong. I am all for cool techy solutions and I was amazed by your approach with the contraints on paths - very mathematical
But you wanted us to tell you

[Martijn]

i would rather have it as separate xml in the addon and not in addon.xml
Doing this would make the repo list even bigger.

[Montellese]

i would rather have it as separate xml in the addon and not in addon.xml
Doing this would make the repo list even bigger.

I'm not sure I understand. What would you like to have as a seperate XML in which addon? The approach here seems to be one addon per controller which IMO makes sense. Does it make a difference for the repo list what is in the addon.xml (apart from the extension points)?

[ironic_monkey]

yes. the repo list is a concatination of all addon.xml's.

[Martijn]

i would rather have it as separate xml in the addon and not in addon.xml
Doing this would make the repo list even bigger.

I'm not sure I understand. What would you like to have as a seperate XML in which addon? The approach here seems to be one addon per controller which IMO makes sense. Does it make a difference for the repo list what is in the addon.xml (apart from the extension points)?

the layout/coordinates as separate file per controller addon

As of now all that is located in addon.xml will also by c/p to the complete addons.xml
http://mirror.nl.leaseweb.net/xbmc/addon...addons.xml
So adding more and more lines will make it bigger and bigger. Doing all the languages in there with our transifex project made a huge impact (which ideally would be split of only to be fetched when actually needed or having that language / offtopic)
Not sure how many controller addons we end up with and how many lines it will be so impact might be nil. Though i think adding the layout to the addon.xml isn't the best option.
Having it as separate layout.xml would be best keeping addon.xml as small as possible.

[Adam7288]

While its definitely over engineered, I applaud you for having a good time with this. Enjoying your work is the key to....continuing the work!

[enen92]

Really cool to see this and your engineering approach to the solution. You also provide us something to learn with the explanation. It might be overcomplicated but definetly sweet and enjoyable both to do and see.

I agree all of this data should be kept away from addon.xml otherwise it might be a common source for issues/errors with other addons or other kodi tools.

Cheers and Thank you for this post

[da-anda]

I'm not sure if this is overengineered if you consider that skins could show the mappings on different places and in different sizes. Would it theoretically be possible to highlight the line of the currently "active" button or give it any other UI effect (depending on skin)?

[garbear]

i would rather have it as separate xml in the addon and not in addon.xml
Doing this would make the repo list even bigger.

agreed, a layout.xml file would be better when generating addons.xml files

If you generate them offline and store them anyway istn't this a bit of over engineering? I don't know how many controllers there are but if you have to set up a mask for each anyway you might as well choose the paths manually

While its definitely over engineered, I applaud you for having a good time with this. Enjoying your work is the key to....continuing the work!

I'm not sure if this is overengineered if you consider that skins could show the mappings on different places and in different sizes. Would it theoretically be possible to highlight the line of the currently "active" button or give it any other UI effect (depending on skin)?

Is this solution over-engineered? I can't say, but I know the questions needed to answer this:

• How many game peripherals are there?
  
• How much flexibility do we give the skin? Do we force skins and layouts to use a single defined vertical spacing and left/right distribution (e.g. 1 label every 100 pixles, centered vertically, with odd numbers of labels starting on the left side) or do we offer skins several configurations of vertical spacing/label stacking?
  
• Do we really want stupid lines anyway? Button labels can also include their mapped value, at the expense of more text on the screen
  

For N controllers and M configurations, the work is either O(N*M) or zero, depending on if we want lines or not.

so:

• Can any gamers out there estimate the number of peripherals?
  
• Can any skinners out there estimate how many configurations skins should have?
  
• Can any users suggest another strategy besides lines?
  

[Adam7288]

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)

http://www.youtube.com/watch?v=bA6PxHKloNg

[Dark_Slayer]

Is this solution over-engineered? I can't say, but I know the questions needed to answer this:

• How many game peripherals are there?
  
• How much flexibility do we give the skin? Do we force skins and layouts to use a single defined vertical spacing and left/right distribution (e.g. 1 label every 100 pixles, centered vertically, with odd numbers of labels starting on the left side) or do we offer skins several configurations of vertical spacing/label stacking?
  
• Do we really want stupid lines anyway? Button labels can also include their mapped value, at the expense of more text on the screen
  

For N controllers and M configurations, the work is either O(N*M) or zero, depending on if we want lines or not.

so:

• Can any gamers out there estimate the number of peripherals?
  
• Can any skinners out there estimate how many configurations skins should have?
  
• Can any users suggest another strategy besides lines?
  

I immediately thought the lines were cool but overkill. I can't say that it would be a "better" strategy but as an alternative my first thought was something similar to Flirc's configuration software. If you've never seen it here's an image


When you click one of those buttons it changes color to green, and then it asks you to press a button to "pair"

My thoughts were maybe complicated or not, perhaps I didn't think it all the way through . . . I was thinking something similar for pairing with the appropriate controller image instead of a keyboard. All standard "arrow" and "enter" inputs from xbmc (keyboard, remote, etc) could navigate through the different buttons allowing you to highlight the one you would like to map. Then pressing enter would keep that button highlighted and give similar text to "press a button on your controller to pair to "A" or "B" (whichever button you were mapping to)

That would just be for mapping. I liked your arrows, so that you could go back and "check" what you had mapped. If "highlighting" is simpler than arrows (which knowing as close to nothing about skinning as a user possibly could, I'd guess that it may be simpler) then you could just enter a dialog that mimics the pairing dialog but this time the text would say something like "Press a button to see where it's mapped" -- then pressing your controller buttons would highlight where they are mapped on the screen.

I don't know if that's particularly easier for skinners, but I don't think any mathematics and line collision formulas are needed

This project has to be the funnest thing I've followed in years