[grumpygamer]

@garbear
here's the idea:

you have the platform list on the right, a logo of the console, some stats
question 1: what stats can we retrieve (Emulator cores? Number of games?)?

there is a list of available controllers with icons, names and battery status if applicable.
question 2: can we have this?

Below the console art and the controllers coming out of it.
Each console has the relative assigned controller icon underneath
If no controller has been assigned an "unassigned icon appears" instead.
question 3: can we see what physical controller is assigned to each virtual controller? This ideally is a MUST HAVE

Underneath each assigned controller we have some options.
I was thinking

• Mapping: default
  
• Reset mapping
  
• Unassign controller
  

Behaviour

You can only navigate the controller section, clicking on the assigned/unassigned controller icon would bring up a pop-up with the available controllers and you'd be able to assign it there or unassign it.
Clicking Mapping: default, would bring up the mapping interface. Once mapping is complete the wording "default" would be changed to "custom". If mapping was incomplete it would have the wording "incomplete".
Reset mapping would just reset the mapping to the default one.
Unassign controller would just remove that controller from that port (could we retain the mapping?).

Thoughts?

[garbear]

question 1: what stats can we retrieve (Emulator cores? Number of games?)?

I don't want to show emulator cores, eventually these will be hidden from the user and things will "just work". Anything else would probably pertain to a game library, which we don't have yet.

there is a list of available controllers with icons, names and battery status if applicable.
question 2: can we have this?

We can show a list physical controllers. Here's what it currently looks like:



We're just missing icons and battery status.

Below the console art and the controllers coming out of it.
Each console has the relative assigned controller icon underneath
If no controller has been assigned an "unassigned icon appears" instead.
question 3: can we see what physical controller is assigned to each virtual controller? This ideally is a MUST HAVE

Not currently. This physical to virtual mapping is done on demand because we don't even know how many ports the libretro core accepts. Snes9x used to crash when a third controller was plugged in.

Underneath each assigned controller we have some options.
I was thinking

• Mapping: default
  
• Reset mapping
  
• Unassign controller
  

Instead of "Unassign controller", "Change controller" with a list of peripherals - controller, lightgun, mouse, unassigned.

Behaviour

You can only navigate the controller section, clicking on the assigned/unassigned controller icon would bring up a pop-up with the available controllers and you'd be able to assign it there or unassign it.
Clicking Mapping: default, would bring up the mapping interface. Once mapping is complete the wording "default" would be changed to "custom". If mapping was incomplete it would have the wording "incomplete".
Reset mapping would just reset the mapping to the default one.
Unassign controller would just remove that controller from that port (could we retain the mapping?).

Sounds good.

A question of my own: what's the most number of players we should support?

[Montellese]

there is a list of available controllers with icons, names and battery status if applicable.
question 2: can we have this?

We can show a list physical controllers. Here's what it currently looks like:



We're just missing icons and battery status.

Battery status support is there for the XInput API on win32 but the joystick API doesn't support retrieving this information yet. Maybe I'll have a crack at it when I got some time.

[grumpygamer]

What time is it there? Is it not 4am?

Regarding question 1: ok no stats
Regarding question 2: Looks enough for me
Regarding question 3: I think we need to find a way to do this, the visual cue of seeing what physical controller controls what port is really valuable.
Regarding unassign inside a list: we can have it inside, but ideally I really don't want to go through a list to get rid of the list item itself - if that makes sense, so I'd keep it outside (as well)

Players:
I'd say 4 players at max for consoles that support it (n64 et similar).

If you want to cater for those strange devices that duplicate game controller ports we can do that too, but I'd hold off for now.
I'd do a basic version avoiding those gimmicks for now.

Mame is another story, yet there are not so many games that support 5+ players, so they can wait for a while.
In Mame's case I think that besides a default mapping for "controller type" (steering wheel, gun, joystick, etc...) I think a per-game mapping is mandatory (later on, ok).

Are we mapping RESET buttons for consoles?

So my real question now is: at what point can we start implementing parts of this to see how it works?
Do you need EVERY image of every console and every controller plus relative icons and ON/OFF statuses before it can be even started?

It would be nice if the system worked with incremental art upgrades so as I complete the art it can be inserted.

[garbear]

What time is it there? Is it not 4am?

maaaaaaybe

Regarding question 3: I think we need to find a way to do this, the visual cue of seeing what physical controller controls what port is really valuable.

I agree, this should happen.

First, we need a way of automatically assigning controllers to ports. My current solution is poor.

Then, this can be shown (and ideally changed) in the GUI.

Regarding unassign inside a list: we can have it inside, but ideally I really don't want to go through a list to get rid of the list item itself - if that makes sense, so I'd keep it outside (as well)

You're the UX guy

Players:
I'd say 4 players at max for consoles that support it (n64 et similar).

If you want to cater for those strange devices that duplicate game controller ports we can do that too, but I'd hold off for now.
I'd do a basic version avoiding those gimmicks for now.

Limiting this to 4 players is OK, but I hold scalability in high regard and want a system that can handle more. If we limit ourselves to 4 players it needs to be a design decision, not an architectural one.

In Mame's case I think that besides a default mapping for "controller type" (steering wheel, gun, joystick, etc...) I think a per-game mapping is mandatory (later on, ok).

Agreed, per-game mapping will need to be possible. This relies on a game database though, and I'm really started to get annoyed at this architectural achilles heel.

I've literally created two game databases so far, one fully integrated into our messy current situation, and one completely separate from everything else. Both were complete failures, because the integrated one just made the situation more messy, and the independent one re-used too little code and became too big a project on its own.

If I attempt another one, hopefully I can find a goldilocks situation that is a compromise between the two.

Are we mapping RESET buttons for consoles?

We map whatever the emulator can support, and reset is built into the libretro API (and thus our Game API), so it's available to all emulators. It's adding one command more than we have buttons for, however, which entails button combos or sequences.

The difficulty is that Reset is not "input" per se, but a Kodi action. Only input is handled by our button mapper. Kodi actions must still be defined by our keymap system via joystick.xml. Allowing Reset to be mapped requires a system that lets ALL Kodi commands be mapped, so basically allowing Kodi to generate a joystick.xml. I purposefully limited my input work to cleaning up joystick.xml, not getting rid of it. One thing at a time. Indeed, though, Kodi actions should one day be mappable in the GUI, so keep this in mind.

On the Xbox, the combo to reset was L+R+Back+Black, which translates to L2+R2+Back+B on the 360 controller. I'll hardcode this into joystick.xml for now so that I can start developing button combos, and maybe one day we'll get GUI support.

So my real question now is: at what point can we start implementing parts of this to see how it works?
Do you need EVERY image of every console and every controller plus relative icons and ON/OFF statuses before it can be even started?

It would be nice if the system worked with incremental art upgrades so as I complete the art it can be inserted.

Then lets make the artwork a resource add-on so that it can be updated independently of everything else.

What I need is more concepts like the one you posted this morning. We need to nail down what's currently possible, and create a priority list for all the "wants" and "nice to haves". Once we get some concepts I can start on the skinning and C++.

[grumpygamer]

Upped PC Engine

[garbear]

nice!

[grumpygamer]

Limiting this to 4 players is OK, but I hold scalability in high regard and want a system that can handle more. If we limit ourselves to 4 players it needs to be a design decision, not an architectural one.

Yep let's keep it a design limitation for now.
I say incremental upgrades is the way to go.

Agreed, per-game mapping will need to be possible. This relies on a game database though, and I'm really started to get annoyed at this architectural achilles heel.

I've literally created two game databases so far, one fully integrated into our messy current situation, and one completely separate from everything else. Both were complete failures, because the integrated one just made the situation more messy, and the independent one re-used too little code and became too big a project on its own.

If I attempt another one, hopefully I can find a goldilocks situation that is a compromise between the two.

Ok I don't really know how to help you out on this one with coding; the only thing I can think of is that IIRC MAME already has a built in per-game configuration.
Maybe you could leverage that?

We map whatever the emulator can support.

This poses a problem if you want to do the emulator-agnostic configuration as one emulator could emulate some features, another could not do so.
Anyway I think we should start from a basic version for people to play with and again... incremental upgrades.
Let's cross that bridge when we get there.

What I need is more concepts like the one you posted this morning. We need to nail down what's currently possible, and create a priority list for all the "wants" and "nice to haves".

One thing I'd like to see here - but let's discuss this - is the ability to switch emulator cores on and off per platform.
I'm not too sure about this, but ideally I don't want a popup asking me with what core I want to play a certain game with every time because some cores don't work, etc.... I just want to hit a key and be playing, that's what I'd like to address.

Maybe make a default core that works with all and then if that crashes it would automatically switch to a different core?
Create another database with what game works best with what core so it just looks it up? (That would be yet another task on my list!)

Yes, from a UX standpoint I think it's getting there; I'll have another play around with it but what you saw there has 4 binned predecessors
I'm not posting everything, just the more refined ideas.
It also tickles me to create a JS prototype, but given how little time I have it will be quite unlikely. I might try and see if I can use some prototyping software...

[garbear]

One thing I'd like to see here - but let's discuss this - is the ability to switch emulator cores on and off per platform.
I'm not too sure about this, but ideally I don't want a popup asking me with what core I want to play a certain game with every time because some cores don't work, etc.... I just want to hit a key and be playing, that's what I'd like to address.

Maybe make a default core that works with all and then if that crashes it would automatically switch to a different core?
Create another database with what game works best with what core so it just looks it up? (That would be yet another task on my list!)

Yes, from a UX standpoint I think it's getting there; I'll have another play around with it but what you saw there has 4 binned predecessors
I'm not posting everything, just the more refined ideas.
It also tickles me to create a JS prototype, but given how little time I have it will be quite unlikely. I might try and see if I can use some prototyping software...

I've purposefully forced the emulator selection on every game launch because I need people to be aware of what emulators they're using for bug reports. It also suggests that trying a different emulator might fix the problem. Of course this will be hidden and things will "just work" in our finished product.

Per-game emulator selection is the end goal, but like other per-game ideas, requires a game database which we are sorely lacking.

Until then, a good first step will be per-platform emulator selection. The database for this can be a simple XML file, like the per-platform button maps. ATM, crash detection isn't an option, thought it's being worked on. We can detect if the emulator fails to launch a game gracefully, though.

Until we have a technical solution for this, I was thinking of just going the low-tech way and relying on user reports about which add-ons work best. I've been sending users to the Github Issues page, so once some more reports come in we'll be able to track which ones are buggy or not. Eventually, it would be nice if the libretro core matrix could automatically show the number of issues open vs closed for each emulator. Got any better ideas?

I considered doing a JS mockup when I did the simple controller dialog, but it's really too much work to be worth it. Just pop out some good sketches and I'll take care of skinning them in Kodi.

[grumpygamer]

upped Gamecube

[garbear]

Nice. I think the RetroArch guys had a lot of problems porting Dolphin to the libretro API, but one can hope!

[grumpygamer]

upped Atari Lynx

[garbear]

Request! Can you do 360 when you get a chance? I'd like to merge the controller input PR with original artwork, at least for the Kodi controller. I'll also experiment with filling and shading the lineart. It would be cool if the skin could define these colors.

[grumpygamer]

The controller only? I might have already done that one I don't remember.
Also at the moment it is only done with strokes, I will have to create a temporary path version big as the one you are using now?
Do you want all the line indicators too?

[garbear]

controller only. transparent png would be easiest because it's support by Kodi, but if you upload a vector image i'll play around a little and export my own png