[cool-pants]

I have looked at the Kodi interface and got familiar with the controller topologies and set up. My doubt is how the multiple controller will be set up. Will they be set up in game, as is the case now, or can be set up beforehand through the settings interface. Also should we keep the multiple controller configuration different for different games?

[cool-pants]

I have looked at the Kodi interface and got familiar with the controller topologies and set up. My doubt is how the multiple controller will be set up. Will they be set up in game, as is the case now, or can be set up beforehand through the settings interface. Also should we keep the multiple controller configuration different for different games?

I am looking into the IConfigurationWindow.h but I am still unsure about where should it be implemented. Like should be it in the game or should it be in the Kodi interface. And after game should both controllers be able to navigate through Kodi or only the one labelled as player one be.

[garbear]

Hi,

Sorry for missing this message, I can disappear for several days at a time due to work/life. Have you read the Player Manager github issue? what makes you interested in this topic?

Regards,
Garrett

[cool-pants]

Hi,

Sorry for missing this message, I can disappear for several days at a time due to work/life. Have you read the Player Manager github issue? what makes you interested in this topic?

Regards,
Garrett

No problem Garrett, and yeah i have looked into the Player Manager issue.
Actually i have worked with configuring multiple controllers for a game we made as a college project and am pretty familiar on the process, the only difference being the code in C#. What makes me interested it the application of C++ on the same topic i have worked at before, Moreover i also liked the concept of retroplayer a lot and use it a lot as well due to me being into retro games like the old pokemon, mario, Doom,etc. I would love to work on something i love while getting more experience on different programming environments.

PS: I will submit my proposal by tonight, this is just a normal reply

Yours Sincerely,
Mainak Sengupta

[cool-pants]

Proposal
The fore-mentioned link contains my proposal for GSOC20.
Can you please critically analyse it and give me some feedback on it.

[garbear]

Nice proposal. Things I like:
 

• Good and clear summary, motivation, benefits and goals
  
• "What does it touch in Kodi" links to code, and it also happens to be the correct code to link to
  

Things I suggest:
 

• Be specific in experience and familiarity
  
• Spell check names
  

You could also add a timeline or design requirements for additional quanitification, though this isn't needed. Juicy technical details show much thought was put in, but it's also not a technical document

The next steps can take place here in the forum, expanding on the project more. Some directions you could take:
 

• What would the UI look like? Do you have mockups?
  
• As a challenge, what is the control path through the code taken by a button press, from when the press is detected to when it reaches the game/UI/mapper? (Second link below might help)
  
• What are all the XML files needed to go from raw driver input to emulator input?
  
• What is the greatest challenge supporting every controller for every emulator/platform?
  

Some resources:
 

• Controller Input for Emulator Development
  
• The lifetime of a button press for peripherals with input
  

[garbear]

A good idea: Call the proposal "Multiplayer" instead of "Multiple Controller Selection". The first is awesome because it focuses on people and an experience, instead of hardware

It certainly changes the scope of the proposal, and might be more intimidating. It's ok to brag about multiplayer and scope the project to the controller selection.

[cool-pants]

Nice proposal. Things I like:
 

• Good and clear summary, motivation, benefits and goals
  
• "What does it touch in Kodi" links to code, and it also happens to be the correct code to link to
  

Things I suggest:
 

• Be specific in experience and familiarity
  
• Spell check names
  

You could also add a timeline or design requirements for additional quanitification, though this isn't needed. Juicy technical details show much thought was put in, but it's also not a technical document

Thank you for your valuable feedback. Sorry on the typo on your name.
I have made most of the specified changes and added a rough timeline.

The next steps can take place here in the forum, expanding on the project more. Some directions you could take:

• What would the UI look like? Do you have mockups?
  
• As a challenge, what is the control path through the code taken by a button press, from when the press is detected to when it reaches the game/UI/mapper? (Second link below might help)
  
• What are all the XML files needed to go from raw driver input to emulator input?
  
• What is the greatest challenge supporting every controller for every emulator/platform?
  

Some resources:

• Controller Input for Emulator Development
  
• The lifetime of a button press for peripherals with input
  

 

About the UI, i am thinking of something along the lines of this


Also i couldn't exactly get the last point. Why exactly should we support every controller for every emulator? As each emulator restricts the type of controller used.
Also we can map a Xbox or PS controller to a SNES controller or a Playstation Guncon and use them like the latter.

[garbear]

About the UI, i am thinking of something along the lines of this

Way cool mockup! That looks great.

Also i couldn't exactly get the last point. Why exactly should we support every controller for every emulator? As each emulator restricts the type of controller used.
Also we can map a Xbox or PS controller to a SNES controller or a Playstation Guncon and use them like the latter. 

Our current input system is actually kind of insane. We have data for the physical location of every button on every controller. The emulator can request an arbitrary controller profile, and the system will physically translate button presses. It's not perfect, but we can get sensible defaults for unseen controllers.

[garbear]

How much do you know about topology? Does this resource make sense?

[cool-pants]

How much do you know about topology? Does this resource make sense?

Yeah it makes perfect sense, and the current way of mapping the driver data is quite amazing, especially the part where multiple profiles mapped to the same driver allows mapping between the drivers as well.

Also, what if during the controller configuration in daisy chain topology, we map only one controller to profile and then use the same profile data for the other controllers as a default. Then allowing the users to tweak them for their respective controllers as per their need. This will remove the hassle for manually mapping all controllers one by one.

[garbear]

Also, what if during the controller configuration in daisy chain topology, we map only one controller to profile and then use the same profile data for the other controllers as a default. Then allowing the users to tweak them for their respective controllers as per their need. This will remove the hassle for manually mapping all controllers one by one. 

Now you're thinking in tree algorithms. And you can't automate a data structure you don't have an algorithm for. To get zero config, I had to accept that the underlying data was a graph, requiring graph algorithms. Would you agree that we're storing a graph?

Here's another fun question, can you find the algorithm in my mockup?

[cool-pants]

To get zero config, I had to accept that the underlying data was a graph, requiring graph algorithms. Would you agree that we're storing a graph?

Well graph algorithms make more sense as the different controller profiles do interact with each other as well. So they are all interconnected, and now that I think about it, the tree topology may also restrict a lot of things, as if we map a faulty controller first, the rest would be affected due to the heirarchy.

Here's another fun question, can you find the algorithm in my mockup?

Well player one is connected to a single controller so that's that .

For player 2 we have 3 different multi taps which I name as A, B and C according to the heirarchy. So we can see that A is connected to B, C and two other controllers while B and C are connected to 4 other controllers.

To search for a specific controller we can either use DFS or BFS for the analysis algorithm. But since we have less number of nodes we can use DFS for more space efficiency at the cost of a little more time to analyse all branches. But at this stage both are pretty much interchangeable.

This will allow the player to chose from a data stack containing all the player profiles topologically sorted.

Also if the controller topology actually represent the controller profiles saved for a driver, we need to search for the most compatible controller profile for a particular game and thus use that for our driver device. If not present then we can then ask for a mapping procedure.

[cool-pants]

But how come player 2 has such a complex controller connection.
Can't we just take controllers from the same connection? Or are they controller profiles linked to Player profile?

[garbear]

But how come player 2 has such a complex controller connection.
Can't we just take controllers from the same connection? Or are they controller profiles linked to Player profile?

It looks like player 2 has a complex connection because all leaf controllers are physically connected through their port. Remember, the SNES only has two ports. A multitap was connected to port 2 for additional players.

SNES controller topology is actually one of the more fascinating ones, not just due to a wide variety of hardware, but also a wide variety of emulators. Libretro enforces a linear controller layout, so each emulator has to map that linear structure to the tree of physical hardware. Of course, each emulator has a different idea of how the list should map to a tree. In order to automate libretro, we need to store a graph that maps a list to a tree (and maybe a dag for the NES 2 Score).

It's best to view an example of all SNES controller and emulator topologies.

There are three classes of controller (physical) topologies: controllers, hubs, and controllers with a hub.
 

• Controller: game.controller.snes, no <physicaltopology> present, first class (controller) assumed
  
• Hub: game.controller.snes.multitap, <physicaltopology> is the only tag present.
  
• Controller with a hub: game.controller.konami.justifier.snes, both layout tags and <physicaltopology> present
  

There are three emulator (logical) topologies right now:
 

• Snes9x/Snes9x2002/Snes9x2010
  
• Beetle bSNES
  
• bSNES Accuracy/Balanced/Performance
  

The last example shows a hub connected to a hub.