[garbear]

Hello, I put together a small idea about how I think it should work.
I have no clue how the machine looks under the hood and doing this is quite difficult from a distance  so I hope I got it right!
Please don't bash me around for the styling etc... it's just a prototype in a VERY infant stage and put together in 10 minutes.

https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

Click the plus symbol to add a controller
then just click thorough it, create another controller and click configure.
Hope this helps

Love the style. Got some comments on the functionality.

How does this scale to 8, or even 16, players? How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox). Also, navigation - this doesn't look too remote friendly, which breaks away from the rest of Kodi.

I feel this is a good starting place, and it looks like it can scale to handle our design requirements. Here's a few:

• User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)
  
• Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining
  
• Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)
  
• User should be able to switch ports
  
• Up to 16 players (via scrolling in the dialog)
  

[grumpygamer]

How does this scale to 8, or even 16, players? 

How does a SNES (for example) do that? Or are you talking about an arcade machine?

How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox).

So you're saying I can add a virtual controller to the SNES emulator and map it on to a physical controller? Or to multiple physical devices?
What's the benefit? It seems such an edge case scenario! Whoever wants to go to that level of sophistication will have the actual machine... 
I am quite perplexed about this, but I'll think about it. 
I certainly don't feel like it's a priority, but you're boss

Also, navigation - this doesn't look too remote friendly, which breaks away from the rest of Kodi.

Yes, yes I know... It was only a basic concept

User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)

Not sure why, but ok..

Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining

No clue what this means...

Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)

Is this the same as the one above: controller mapped to 3 devices at once?

User should be able to switch ports

Yep, cool

Up to 16 players (via scrolling in the dialog)

Again, this seems valid for arcades, but not so much for home consoles... anyway this shouldn't be too much of an issue.

[garbear]

How does this scale to 8, or even 16, players? 

How does a SNES (for example) do that? Or are you talking about an arcade machine?

I'm talking about any game. Arcade machines. I think Genesis supports two 4-player hubs. If we hard-code a 4-player limit now, it will be prohibitively expensive to change this later.

How does the player choose which virtual hardware is in use? Some SNES games react differently depending on if a Multitap is attached or not. Which means that one player can have multiple virtual devices (multitap + controller for SNES, or joystick + mouse + keyboard for DOSBox).

So you're saying I can add a virtual controller to the SNES emulator and map it on to a physical controller? Or to multiple physical devices?
What's the benefit? It seems such an edge case scenario! Whoever wants to go to that level of sophistication will have the actual machine... 
I am quite perplexed about this, but I'll think about it. 
I certainly don't feel like it's a priority, but you're boss

Certainly not a priority, but a design requirements nonetheless. We don't have to launch with this feature, but we can't choose an architecture that prevents this, unless we change our design requirements.

User must be able to map controller to up to three devices at once (mouse, keyboard and joystick)

Not sure why, but ok..

Think about a joystick DOS game that requires the enter key or a mouse action to launch. Omitting this feature would preclude these games. We can certainly do this if we change our design requirements, otherwise we have to support this edge case.

Dialog must respect both physical and logical topological restraints (see examples of physical topology and logical topology) including hubs and daisy chaining

No clue what this means...

Topology is how things are connected. I've split this into two kinds of topologies:

Physical topology is how devices physically connect to each other. For example, you can physically plug a multitap into another multitap. Physical topology obviously can never change.

Logical topology is what the emulator logic can handle. This is strictly a subset. For example, you can physically plug a multitap into a multitap, but there's no emulator logic that can handle this, so it's not allowed. Logical topology can be different for each emulator and change over time.

Topology is important because it lets us describe things beyond the trivial topology of a direct controller-console connection. Without topology, we couldn't describe hubs or daisy chaining.

We have a difficult job. Our data is described topologically, but we need to hide this complexity from the user. However, the simpler the dialog, the more work needs to be done under the hood. I'm hoping to find a happy medium.

Dialog must support multiple physical controllers per each virtual controller (allows turn-based multiplayer e.g. Monopoly and some multiplayer handheld games)

Is this the same as the one above: controller mapped to 3 devices at once?

No, this is exactly the opposite - 3 physical controllers mapped to a single device. The inputs are multiplexed together so even though it's three people, it looks like a single player to the emulator.

This design requirements came from a forum request. Like all design requirements, it can be dropped, but this is something we need to decide to do.

[grumpygamer]

Hey, I have read the above, I still don't get all the topology thing, but I will re-read it maybe tomorrow.

I am happy to take on board all your requirements and try to find a way to make it simple for people to configure, but I honestly think it's a bit overcomplicated for a launch.
I experience this nearly on a daily basis, the project is big, it has to have bells and whistles and support every possible scenario, but in the end it's very hard to launch with all the features fully fledged in a reasonable amount of time.

My approach to this would be to leave the code "open" so that the bells and whistles can be developed at a later point and start with a simple thing that just works.
Then slowly add features you were mentioning, the UI will change to accomodate the new functionality.
I think all software nowadays tends to do it like that, but maybe I'm just speaking rubbish.

At the end of the day I doubt that the average player who wants to use emulators has the need for a "multitouch" interface or some other fancy thing, but most users would probably prefer having a working rom browser that elegantly loads the game (for example)

Baby steps of things that work - and then expand from there - is what I've grown up to understand.
I just want to point out there is no offence meant here, nor critique, just expressing my point of view.

I will try and see what I can get done in regards to what you have explained to me.
Thanks

[garbear]

My approach to this would be to leave the code "open" so that the bells and whistles can be developed at a later point and start with a simple thing that just works.

You are as wise as you are grumpy I'm perfectly happy shipping a stripped-down GUI initially.

My main concern is the backend code, due to my experience with the controller dialog. That project had equally steep design requirements, and look at how long it took (almost a year). It was such a massive project, that every time I adjusted the design due to a newly discovered joystick driver bug, I would spend days, if not weeks, making a single change.

There's a difference between leaving holes in the implementation and leaving holes in the architecture. Adding code is cheap. Refactoring code is expensive. Would you say GUIs follow this same pattern? I wouldn't, because a GUI is a single presentation layer. The joystick code, on the other hand, is built of around 5 layers of abstraction, from the bools and floats of the driver layer to the physical features of the controller profile layer.

Anyways, I think we should build the GUI in a series of steps, from simple (basically what you posted) to fully-featured. In order to build your concept, we need player profiles. How do you think these should work?

[da-anda]

Think about a joystick DOS game that requires the enter key or a mouse action to launch. Omitting this feature would preclude these games. We can certainly do this if we change our design requirements, otherwise we have to support this edge case.

a keyboard can't be owned by a player as there can be at lest two players on one keyboard (I remember playing DOS games with my brother on one keyboard). So there can only be a virtual abstraction of the keyboard which is mapping specific keys to a certain player. But how these keys are mapped must not be controlled by Kodi - it actually can't be controlled by Kodi. If player One is using WASD and player Two the cursors must be in the domain of the game, because the Keyboard must still stay a generic input device to f.e. enter a nickname on highscores or do whatever textinput required.

Regarding the mapping of multiple controlers to one user: I think the approach from Grumpygamer would still work for this. All we have to do is to split the management of players and controllers. So you first add a player, give it a nickname and maybe even an avatar, and in a second step you manage it's controllers using the same technique Grumpygamer demoed (click "add controller" in UI, click any button on controller, done). But I honestly don't see that we really need a complex controller matrix that shows which controller is mapped to which user as long as it's just two clicks to remap a controller to another user via Game OSD

[OmniBlade]

Regarding grumpygamers question about consoles with up to 16 players... I don't think any support that many, but the saturn supports 12 players on some games (using 2 x 6port multitaps) and the first Playstation supports up to 8 (2 x 4port multitaps), both of which currently have libretro implementations.

[grumpygamer]

yep, what is the likelihood that most player are going to use these?
I am still looking into this, but I would just ship the basic stuff initially and then expand later.
Anyways I might have time to have a better look this evening and update the prototype.
Also I have no idea where these "expanders"/"hubs" are attached to
Is there any logic behind these?
For example if they are attached to a game port you can't add one of these virtual controllers if 2 controllers are already plugged in

[grumpygamer]

Hello, I have had another go at this.
It's by no means complete and design is still crap and irrelevant at this point, but try both journeys.

1. Add one device (substantially unchanged)
2. Add a virtual device (hub multiplier) and then add controllers to it

Let me know your thoughts.



https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

[OmniBlade]

Its tricky because the cores implement this in one of two ways. The first way (and the way I was told to do it when I added it to the saturn yabuse core) is to have it as another input option, so for ports 1 and 2 you have the normal controller options and then all the normal controller options again plus the hub attached. When the hub options are selected, the couple of cores I looked at did whatever they did to set the multitap modes on and then just acted as if that controller port had the normal controller attached. The other way is the way the Mednafen PSX core did it at the time (not sure if its been conformed to the first way since, I've not use it in a while) was to have it as a core option that you toggled. IMO this resulted in a much cleaner interface, but seems it was not the way that was preferred by the main retroarch devs at the time.

Another complicating issue is that games that aren't multitap aware for any of these consoles may behave oddly if one is attached (This happened on the original systems as well for the most part due to how the hubs operated), so really to get the cleanest interface would require a game db that stored info on if the game even supported having the multi tap hubs enabled so the correct number of controllers could be presented as options.

Hello, I have had another go at this.
It's by no means complete and design is still crap and irrelevant at this point, but try both journeys.

1. Add one device (substantially unchanged)
2. Add a virtual device (hub multiplier) and then add controllers to it

Let me know your thoughts.



https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

[grumpygamer]

Its tricky because the cores implement this in one of two ways. The first way (and the way I was told to do it when I added it to the saturn yabuse core) is to have it as another input option, so for ports 1 and 2 you have the normal controller options and then all the normal controller options again plus the hub attached. When the hub options are selected, the couple of cores I looked at did whatever they did to set the multitap modes on and then just acted as if that controller port had the normal controller attached. The other way is the way the Mednafen PSX core did it at the time (not sure if its been conformed to the first way since, I've not use it in a while) was to have it as a core option that you toggled. IMO this resulted in a much cleaner interface, but seems it was not the way that was preferred by the main retroarch devs at the time.

Another complicating issue is that games that aren't multitap aware for any of these consoles may behave oddly if one is attached (This happened on the original systems as well for the most part due to how the hubs operated), so really to get the cleanest interface would require a game db that stored info on if the game even supported having the multi tap hubs enabled so the correct number of controllers could be presented as options.

Hello, I have had another go at this.
It's by no means complete and design is still crap and irrelevant at this point, but try both journeys.

1. Add one device (substantially unchanged)
2. Add a virtual device (hub multiplier) and then add controllers to it

Let me know your thoughts.



https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

I get that the UI has been previously adapted to developer's needs, but ideally we want the UI for the users so they have a seamless experience.
After all it's not called DI...

I think devs need to think of a way of accommodating for a streamlined experience. How they do it...? I don't know.
The game database idea is not bad, not sure if there is a similar ongoing project around the board... I think I saw one at a point.

[garbear]

Think about a joystick DOS game that requires the enter key or a mouse action to launch. Omitting this feature would preclude these games. We can certainly do this if we change our design requirements, otherwise we have to support this edge case.

a keyboard can't be owned by a player as there can be at lest two players on one keyboard (I remember playing DOS games with my brother on one keyboard).

This is a valid use case. However, the GUI is agnostic to the fact that there's two players. We can fix this, because we have the requirement to support joysticks that use keyboard drivers. Normally, keyboard keys are mapped to emulated joysticks. Then we simply map each emulated joystick back to the keyboard. Viola, the GUI is aware of both players and they can easily switch WASD and arrow controls without switching locations.

So there can only be a virtual abstraction of the keyboard which is mapping specific keys to a certain player. But how these keys are mapped must not be controlled by Kodi - it actually can't be controlled by Kodi. If player One is using WASD and player Two the cursors must be in the domain of the game, because the Keyboard must still stay a generic input device to f.e. enter a nickname on highscores or do whatever textinput required.

After mapping the keyboard to a joystick to a keyboard, all remaining keys can fall through and be used as keyboard keys. Players can switch WASD with arrows in the GUI without affecting the rest of the keyboard.

[garbear]

Hello, I have had another go at this.
It's by no means complete and design is still crap and irrelevant at this point, but try both journeys.

1. Add one device (substantially unchanged)
2. Add a virtual device (hub multiplier) and then add controllers to it

Let me know your thoughts.

https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

I noticed this mockup uses two lists, players and virtual devices. This is much closer to supporting our requirements. The configuration flow, walking users through the setup process, makes it much less confusing. Good job.

The max player count is a great addition.

This dialog handles SNES well. Here's some use cases we also need to support:

• Sega Saturn can support 12 players using 2 x 6port multitaps.
  
• The 3DO has a single port and controllers/lightguns are daisy-chained.
  
• DOSBox maps the keyboard to two 2-button joysticks, and remaining keyboard keys and mouse input falls through
  
• DOSBox maps the keyboard to two emulated joysticks which are mapped back to the keyboard, remaining keys and mouse fall through
  
• DOSBox maps two physical game controllers to keyboard and mouse input
  

The advantage of my DI (lol) is that it is much closer to what is possible with our skinning limitations. My mockup probably requires another three weeks of work.

Your user interface will be very difficult to build with our skinning engine. I estimate it would take at least four months of work to build this in its current state. In particular, lines are extremely difficult. We can't make pngs of every possible line configuration for every platform. This just doesn't scale.

Algorithmically generating lines is a possibility. See my experiment here: https://forum.kodi.tv/showthread.php?tid...pid1932869

[Julipo]

With all this virtual and physical configs, for people that mostly (or only) will play single player games, and possibly with one pad and/or one keyboard (so don't need to think about 2º player, multitaps, etc.): Is it possible configure one time (only one) my gamepad and/or my keyboard and use this configuration in all cores (at least in all cores that use normal gamepads: psx, snes, genesis, if they are some outlier that need keyboard, ignore it)? (Something simmilar to RetroPad in RetroArch)

[garbear]

Is it possible configure one time (only one) my gamepad and/or my keyboard and use this configuration in all cores (at least in all cores that use normal gamepads: psx, snes, genesis, if they are some outlier that need keyboard, ignore it)? (Something simmilar to RetroPad in RetroArch)

The RetroPad is part of the libretro API. Kodi is built on the libretro API. We inherit all the good things about the RetroPad, like the ability to configure one controller for all cores. This won't go away. Kodi just adds the optional ability to specialize configurations per-platform.

The libretro API also allows a users to switch virtual devices. Does RetroArch expose this? That is what the Player Manager is built for - exposing this part of the libretro API to the user.