[nonob]

Hello,

Is snes multitap and nes Four Score actually supported in official stable Kodi 18.1 ? I  can't use more than 2 players. It's ok in RetroArch.
If not, is it in devellopement and will it be supported in a next release ?

Thanks.

[garbear]

The Player Manager is in development. See https://github.com/garbear/xbmc/issues/87 . Long way from being done, but you can see how much has been accomplished.

[nonob]

Hi,

It's look promising

So actually i can't use more than 2 players with nes and snes emulator ? Should i create new issues on Github for that, or just wait ?

[KOPRajs]

Hi,
it seems like finishing the Player Manager is what we need to fix this issue: https://github.com/kodi-game/game.libret.../issues/22

I do like the idea with 2 separate windows (controller types and controllers) both available from the game OSD menu, but I'm not sure what do we need the avatars and names for? Is it supposed to be used for the Netplay?

I think we can divide the project into 2 parts which can be implemented separately.

The first part would be to set the controller types (basically generated from the topology.xml). I'm not sure how the proposed solution on the picture would work, but I think we would be fine with very simple standard Kodi settings dialog like this (e.g. for PSX):

Code:


Controller types

Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad, ps.multitap)
Multitap 1 Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 3: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 4: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad, ps.multitap)
Multitap 2 Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 3: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 4: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2


The default would look like this:

Code:


Controller types

Port 1: dualanalog
Port 2: dualanalog


For now we would save this settings for every topology.xml (for every emulator).
In the future we can use the Kodi video settings approach and save one default setting for every topology.xml and then settings per game in the game db. In such scenario we would add one more button "Set as default for all games" (with the same topology.xml).

[garbear]

I like your idea much better than mine. My demos were more a visualization of the nitty-gritty details, and for sure we should make everything as simple as possible.

Controller types

Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad, ps.multitap)
Multitap 1 Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 3: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Multitap 1 Port 4: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 1
Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad, ps.multitap)
Multitap 2 Port 1: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 2: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 3: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2
Multitap 2 Port 4: (choose from ps.dualanalog, ps.dualshock, ps.gamepad) - only visible if ps.multitap is choosen on Port 2

Inside what you posted there's actually a tree. That's what the screenshots were for, they visualize this tree. It uses a "tree drawing algorithm". It's how the binary API works, and we certainly shouldn't expose the complexity to the user like in my screenshots.

Inside your post there's also a list of lines. Trees can be converted to lists easily, which is why topology.xml exists - it defines how to translate between the messy details used internally to the simple example you posted.

Now if only I had time to build what you posted

[KOPRajs]

So I did a little mock-up of the proposed solution for the controller types part, because visualization always helps!
https://imgur.com/a/vRNDrC2





- Content would be loaded from the topology.xml for the current game add-on.
- Default for every option would be the first item in the topology.xml.
- For now we can save the settings as default for all games to settings.xml in the .kodi/userdata/addon_data/game.* directory or as topology.xml if we don't want to mess with the settings.xml.
- In the future we can save the settings for specific games (in the game database).
- The "Set as default for all games" would remove all the game specific settings for the current game addon from the database and save the default for all games to settings.xml in the .kodi/userdata/addon_data/game.* just like the "Set as default for all media" does for the videos.

EDIT: "Port settings" or "Port configuration" might be a better name for this window.

[garbear]

I gave it a try to see how far I could get today. I managed to finish adding the dialog and it's all set up to list ports.

[garbear]

Now it's all hooked up to topology.xml. We need some basic XML persistence and a skinner's love now, but it's looking pretty good.

[garbear]

Adding controller selection selection was pretty straight-forward

[garbear]

Getting closer

[garbear]

I have an initial version done. There's no persistence, which is kind of annoying. There's no skinning either. Multitaps are supported, but not via the non-standard Libretro Options API that the PSX cores use. But it solves the problem of switching to the Gamepad.



I'm uploading test builds, I'll link when they're ready.

[KOPRajs]

Great to see the progress!

What is "the non-standard Libretro Options API that the PSX cores use"?

Does it solve these issues?
https://github.com/kodi-game/game.libret.../issues/11
https://github.com/kodi-game/game.libret.../issues/22

[garbear]

As promised, builds of the new Port Setup dialog (without persistence) have been uploaded: https://github.com/garbear/xbmc/releases...2-20211018

 

What is "the non-standard Libretro Options API that the PSX cores use"?

Does it solve these issues?
https://github.com/kodi-game/game.libret.../issues/11
https://github.com/kodi-game/game.libret.../issues/22

Here is the setting:



Here are the options for the setting:



Notice how the setting is buried in a sea of unrelated, non-standardized options. There's no way to robustly define a parsing mechanism to handle multitaps via the libretro options API. Not only that, but the options API v1 is deprecated for v2, which we don't even support yet.

Instead, see how bsnes-mercury does it: https://github.com/libretro/bsnes-mercur...ro.cpp#L24

The SNES multitap is a subclass of a joystick, and when assigned to a port it virtually connects a multitap. bSNES Mercury then does depth-first player assignment, as you saw visualized in my earlier ugly screenshots.

Because of the depth-first player assignment, the API technically models a tree, and trees are hard to design an API around. Libretro avoids the problem and as a result all cores have to do something different to support Multitaps. Our Game API actually formalizes the tree, and it's trivial to convert to the SNES approach. However, it would be extremely difficult to translate our API's tree to the idiosyncratic PSX approaches, and due to the v1 deprecation it's not worth it to try.

[KOPRajs]

Notice how the setting is buried in a sea of unrelated, non-standardized options. There's no way to robustly define a parsing mechanism to handle multitaps via the libretro options API.

Right you are! 

Here is an idea for a possible workaround. What if we change the topology.xml for this specific add-on to simply have 8 primary ports (all the same with the 3 gamepad types and without the multitap options). Basically it would mimic the PCSX internal logic and it might work. The ports 3-8 are simply going to be ignored without the multitap enabled in the add-on settings.

[garbear]

OK, so change topology.xml to have 8 primary ports with the multiple gamepad types. Would we have to force the multitap setting and/or hide it from the user?