[grumpygamer]

Hey, sorry to hear about the fire...
Sounds like one of those disaster movies, except it's for real...
Good job everyone's alive.

I am home from Thu this week to next Tue so if you ever want to have a call I'm happy.
Just saying as you probably have more important things to attend to.

[garbear]

My hotel's free internet is throttled to 1Mbps, so it'll be best to wait for the evacuation order to be lifted (should be within the next week).

I've created an issue for remaining tasks to complete the latest mockup: https://github.com/garbear/xbmc/issues/87 . I'll keep this updated as our design requirements evolve.

New in the next build will be support for a bunch of Sega Saturn controllers: https://github.com/kodi-game/kodi-game-c...rs/pull/12

[garbear]

I finished designing the algorithm for mapping players to ports. This is something missing from the libretro API. As a result, cores do whatever the fk they want, including adding a setting for every port (beetle saturn) and simply failing when a multitap is in only port 2 (yabause).

The way it works is by first building a tree of controller connections (the topology). The root node is the virtual game console. Multitaps and daisy chaining are branches in the tree. Each node is associated with a controller profile, or in a disconnected state.

The port-to-player mapping is then a straightforward depth-first walk of the tree. This means that hubs are explored before controllers. The next player slot is assigned to the first controller that provides input, and the walk continues.

To show the topology in the GUI, I created a tree-drawing algorithm that draws the tree to a grid. Each column in the grid maps to a player, and navigation is intuitive with a remote:



I've extended the algorithm to handle many of our design requirements. For example, DOSBox requires daisy-chaining joysticks and mouse/keyboard input:

[grumpygamer]

Hello everyone and happy holidays!
I have unfortunately been sick the whole holiday I was telling you about further back and have only just started recovering!  
Anyways I saw these mockups and I have no clue what they're about! It seems waay too complicated!
I do however really like the avatars.
For me it makes no sense to have controllers attached to players that way, it seems a bit counter-intuitive, also it seems that one player has a hub then another hub  with a joystick with another hub... etc etc...

o0

I think as a user I just want to play a game, I'm not sure I want to know about all that stuff, even in the ultra-rare scenario where I want to play a 90 player game on a SNES with 200 Hubs I'm not sure I'd want to delve into configuring all the hubs and all that...
I am left wondering if it would be better for the system to figure out how many players you want and map them automatically with a hub or the likes...

Also I think the view would not be player with joystick... as the joystick is not physically attached to a player (I've never heard such fetishes, but one never knows hehe), but maybe the avatar could sit under the playing device.
Anyways I'll try and mock something up soon.

Hope Garbear's situation has been getting better!

[garbear]

Glad to hear you're on the recovery end! The wildfire is now the largest in recorded California history. Things have normalized since our two-week evacuation, but half our neighborhood is charred rubble and chimneys. Fortunately my house took almost no damage. The fire took half our yard but was stopped by a stone path that bisects the yard. Hard to believe how lucky we are.

Anyways I saw these mockups and I have no clue what they're about! It seems waay too complicated! I do however really like the avatars.

At least they're an improvement over the beast of complexity that was my first attempt!

The player window has two purposes - assign people to console ports, and assign virtual hardware to console ports. I suppose this could be simplified by splitting these tasks into two windows?

For me it makes no sense to have controllers attached to players that way, it seems a bit counter-intuitive, also it seems that one player has a hub then another hub  with a joystick with another hub... etc etc...

The problem is we need a single standard for how to attach controllers to players. The standard I've illustrated is called "depth-first" because players are assigned by expanding hubs first before visiting subsequent ports. The alternative is "breadth-first". Do you think this would be more intuitive?

The mockup with the three hubs is just an example to show how the depth-first assignment works. In practice, emulators will limit each port to a single hub.

I am left wondering if it would be better for the system to figure out how many players you want and map them automatically with a hub or the likes...

There are two problems.

One, the system doesn't know how many players you want. Due to joystick driver bugs, some controllers are "ghost" controllers (like PS4 motion controls). Some joysticks use keyboard drivers, so they're not visible to the system.

We can certainly guess the number of players and set the hubs automatically, but that leads to the second problem - hubs are unsafe. Some SNES games don't work if one is attached.

Also I think the view would not be player with joystick... as the joystick is not physically attached to a player (I've never heard such fetishes, but one never knows hehe), but maybe the avatar could sit under the playing device.

My decision to put the players above the controllers is partially due to my joystick fetish, but also because my avatars came with parachute frames, so dragging them upward on a touchscreen will cause them to deploy their parachute and float back down.

The skin actually has control over this. It can place the controllers above or below the avatars, and the controller vertical alignment and navigation take this into account. So we could choose either layout for Estuary.

Anyways I'll try and mock something up soon.

Looking forward to it! Let's aim for a hangout next week.

[natethomas]

My decision to put the players above the controllers is partially due to my joystick fetish, but also because my avatars came with parachute frames, so dragging them upward on a touchscreen will cause them to deploy their parachute and float back down.

LOL. Maybe it would be easier to see how this works in action, instead of with screenshots?

[garbear]

My decision to put the players above the controllers is partially due to my joystick fetish, but also because my avatars came with parachute frames, so dragging them upward on a touchscreen will cause them to deploy their parachute and float back down.

LOL. Maybe it would be easier to see how this works in action, instead of with screenshots?  

Not screenshots, photoshop mockups. I'm still working on the code that translates the configuration you see to the libretro API, which is an utter mess when it comes to multitap support. Also I'm waiting on grumpy's ideas to see if anything fundamental should be changed.

[RockerC]

My decision to put the players above the controllers is partially due to my joystick fetish

What do you mean by "fetish"? You can never have too many gamepads, joysticks, or arcade fight sticks in your collection! This enthusiasm for game controllers is perfectly normal! 

[Solo0815]

I'd have 2 windows for the "PlayerManager"
1. System independent: assign Human-Players to "physical Controllers" and set a Avatar
maybe with a name -> Avatar-name.
e.g. Controller: Gamepad Pro, assigned to"Ninja"
Controller: Keyboard, assigned to "Cat"
Then every human-Player has to remember his Avatar

2. System specific: select, how many Controllers are connected to a system and assign a Avatar to every System-specific ontroller
e.g. SNES:
1st Port: SNES Controller, assigned to "Cat" -> is controlled with Keyboard
2nd Port: SNES Controller, assigned to "Ninja" -> is controlled with Gamepad Pro

e.g. DosBox
Player one assigned to "Ninja" (Gamepad Pro)
Player two assigned to "Cat" (Keyboard)

The only problem I see, is that Dosbox has to display the "psysical" Controller e.g. Keyboard

I'm looking forward to the mockups

[OmniBlade]

I would suggest not bothering displaying the presence of multi-tap adapters. As far as a user is concerned, if a game supports up to X players, they just need to assign X joysticks and RetroPlayer should abstract the actual activation of multitap(s) in the core as required. The fact that the physical hardware required additional peripherals to support connecting multiple controllers shouldn't impact on how the controller UI is used IMO.

[RockerC]

@garbear regarding hubs, multi-tap adapters and port-expanders, have you gotten yourself a "Bliss-Box 4-Play" (a new universal gamepad adapter) which is now nativly supported by RetroArch?

Any chance for Kodi support it the same way as RetroArch too in order to support four players on one of these Bliss-Box 4-Play converter boxes?
 

• https://www.libretro.com/index.php/bliss...n-is-here/
  
• http://skunx7.wixsite.com/bliss-box
  
• https://www.facebook.com/blissboxadapter/
  

"RetroArch has support for many adapters and the ability to add countless more, however, it does so by mapping per adapter. Similarly, the 4-Play also supports a large number of controllers but outputs them as one device.  Previously, RetroArch could not map each game pad because of this. Fortunately, the 4-Play was designed with this in mind and has a built in API any project could take advantage of without the need of drivers. In this update of RetroArch each pad seen by the 4-Play is read in to RetroArch appending the pad type to the cfg file found during controller detection.

This is just the beginning and there is a road leading to amazing potential with the 4-Play adapter. Using the same API mechanism, we could expect to see but not limited to: native game pad communication with Gamecube and Dreamcast, direct memory card support and LCD screen writing, support for all 12 Playstation 2 pressure buttons, and more. The latest version of the 4-play firmware is required and you must configure your 4-play with the API tool available on the Bliss-Box page for download.

In addition the new firmware from Bliss-Box gives each player a unique USB ID. This allows players to be specific to the physical ports. Each USB name has a number indicating the player order."

   


Bliss-Box 4-Play currently supports the following controller ports but more controller ports can be added with new cables and firmware updates:
 

• Super Nintendo Entertainment System ( snes )
  
• Nintendo Entertainment System ( nes )
  
• Nintendo Virtual Boy
  
• Nintendo 64 ( n64 )
  
• Nintendo GameCube ( gc )
  
• Nintendo Wii Remote Expansion Port
  
• Sony PlayStation/PlayStation 2 ( psx ps2 )
  
• DB9 (Sega SG-1000, Sega Master System, Sega Genesis, Atari 2600, Atari 7800, Commodore 64, Commodore Amiga CD32, ColecoVision, Mattel Intellivision, Amstrad GX-4000, Panasonic 3DO, Bally Astrocade, Sinclair ZX Spectrum)
  
• Sega Saturn
  
• Sega Dreamcast ( dc )
  
• DH15 (Atari 5200, SNK Neo Geo AES)
  
• Atari Jaguar
  
• NEC PC Engine / TurboGrafx 16 (Full/Mini)
  
• NEC PC-FX
  
• GCE Vectrex
  
• Apple Bandai Pippin ATMARK
  

[garbear]

I'd have 2 windows for the "PlayerManager"
1. System independent: assign Huzman-Players to "physical Controllers" and set a Avatar
maybe with a name -> Avatar-name.
e.g. Controller: Gamepad Pro, assigned to"Ninja"
Controller: Keyboard, assigned to "Cat"
Then every human-Player has to remember his Avatar

Like this?



How do you determine the number of players? Maximum player count is system-dependent.

Absent is player names. Given that these are an arbitrary length, we can't fit these into a horizontal layout. A vertical layout could be used, but it will be much harder to fit 12 players, and we'd lose the running animations when avatars move side-to-side.

I'd have 2 windows for the "PlayerManager"
2. System specific: select, how many Controllers are connected to a system and assign a Avatar to every System-specific ontroller

How would we assign 5 avatars if only two controllers are attached to be given avatars?

I'd have 2 windows for the "PlayerManager"
e.g. SNES:

1st Port: SNES Controller, assigned to "Cat" -> is controlled with Keyboard
2nd Port: SNES Controller, assigned to "Ninja" -> is controlled with Gamepad Pro

Is this satisfied by the system-dependent mockups I posted a while ago?

I'd have 2 windows for the "PlayerManager"
e.g. DosBox
Player one assigned to "Ninja" (Gamepad Pro)
Player two assigned to "Cat" (Keyboard)

The only problem I see, is that Dosbox has to display the "psysical" Controller e.g. Keyboard

I'm not sure what your idea is exactly, can you be more descriptive?

I would suggest not bothering displaying the presence of multi-tap adapters.

Unfortunately we can't avoid this, as users need to configure multitaps until we have a database that says which games support them and which bug out when one is attached.

As far as a user is concerned, if a game supports up to X players, they just need to assign X joysticks

Is this solved by the separate non-system-dependent mockup I posted here?

[garbear]

OK, another round of mockups. I took the advice here and separated this into two windows. The player window is now devoted entirely to players and their avatars:



I added a new button to the in-game OSD:



It opens up a window devoted entire to game controls:



The text at the bottom of the Controls window shows the name of the virtual or physical controller highlighted. Should I do something similar for avatars?

[Solo0815]

I'd go for a vertical alignment in columns. Why:
1. there is IMHO more space
2. It fits to the ideas below

Player Window:
How are the player-Avatars assigned to the port numbers?
Do you think about adding/giving avatars names? Then 2 columns would look better:
https://imgur.com/a/aNtt6
There could be a scrollbar, if there are more Players/Spectators that fit on the screen and there is space for the name. I think later the netplay-feature from retroarch will be supported and tere may be many ppl in the "Lobby". Then they can be all displayed with their name.

Game Control window:
Also vertical alignment. I have no time at the moment to do another mockup, but I'm trying to explan it here:
First the window can look like this:
The "***" are separators for the comulmns.
Port Nr. *** Pic of VirtualController *** Avatar     *** Name *** GameControllers (there could be more in that row) (description)
1            *** SNES                             *** Cat(Pic)     *** Cat    ***
2            *** SNES                             *** Ninja(Pic)  *** Ninja ***

Then you can highlight a Port and then a window could open with
"Press a button on a controller to control $Avatar"
The user presses a button to assign a Controller e.g. Xbox Gamepad to the Port. In the second iteration the user can assign a Keyboard to Port 1 and Gamepad Pro to Port 2.
Then the window could look like this:

Port Nr. *** Pic of VirtualController *** Avatar     *** Name *** GameControllers (there could be more in that row) (description)
1            *** SNES                             *** Cat(Pic)     *** Cat      *** Xbox Gamepad, Keyboard
2            *** SNES                             *** Ninja(Pic)  *** Ninja    *** Gamepad Pro

I hope that I gave you some ideas to improve RP

[grumpygamer]

Hello!
Sorry, a lot going on here, barely find time for anything "leisurable"!  

Anyways I had a look at a different way of mapping devices...
This is not yet finished, but I thought I'd share anyways...

Keeping into consideration that I think the user should not know about port expanders, but just care about adding players, here's a slightly different approach:

Step 1:
You just add something to the console, if it's a port multiplier then you just cascade the controller another level down, otherwise you just add an input device.
How that is that you can recognise what that input device, I do not yet know, but I'm assuming you'd know the vendor.
If you don't know the vendor, just put a generic joystick icon.

If you want you can add another device to that controller (Keyboard and mouse?) and that would cascade on the same level of the input device

Step 2:
Assign the avatar to that input "scheme"

Step 3:
Choose the manual mapping to then map buttons to other buttons.
In case of multiple peripherals mapping to the same controller there would be multiple screens.

Once the mapping is done you can add more controllers/hubs/whatever to the max supported

I do apologise for the quality of this as it is unfinished and also am missing loads of sceanrios. but I thought I'd share before I got caught up again with life.

https://xd.adobe.com/view/58f3c059-94be-...aa5a9c1fa7