Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Controller topology (multitap support) #13499

merged 3 commits into from Feb 16, 2018


Copy link

garbear commented Feb 8, 2018

This PR contains the final architecture needed for the Player Manager. Whereas #13374 abstracted keyboards and #13482 abstracted mice, this PR presents an abstraction for multitaps (aka hubs).

The conclusion of the Controller Topology Project is significant because we can, for the first time, model how controllers connect to and map to each other for all of gaming history.

ps multitap


At the highest level, this PR adds a new concept to the Game API: the controller topology. A topology defines how things are connected, so this concept lets the player manager reason about how to automatically connect input devices to the console and to each other. This happens without any user effort.

To give a concrete example, SNES and Genesis consoles only have two ports, but they support up to 5 controllers with a multitap. However, multitaps break some games. We can safely default to 2 controllers, and when a new user joins, the (future) Player Manager automatically swaps player 2 with a multitap, then connects player 2 and player 3 to the multitap's ports.

Controller topologies have been expanded to support daisy-chaining as well. For example, the 3DO had a single port, and up to 8 controllers could be daisy-chained together. This will be reflected in the Player Manager where it's impossible to have a player 2 without a player 1.

Finally, a distinction is made between the physical topology and logical topology. The physical topology defines how controllers physically connect together. For example, you can plug a multitap into a multitap. The logical topology defines a subset of those connections that the emulator's logic supports; obviously no emulator allows a multitapped multitap, so even though this is physically possible, it is disallowed.

Motivation and Context

Like all other input features, this came about while trying to automate a part of the libretro API. While awesome at what it does, the libretro API makes emulation horribly inaccessible to users who don't have any concept of what a RetroPad or a Multitap is.

How Has This Been Tested?

Configuring multitaps requires a Player Manager, which is still in progress. For now, game console ports are hard-coded to accept the first controller specified by their topology.

Tested with controllers, keyboards and mice and various emulators on Linux and OSX.

Android requries kodi-game/kodi-game-scripting#19 to fix game add-ons.

Game add-ons on Windows broke after #13140. I'd appreciate help fixing this.

Screenshots (if appropriate):

A (theoretical) example of how depth-first controller-to-player assignment works:


Types of change

  • Bug fix (non-breaking change which fixes an issue)
  • Improvement (non-breaking change which improves existing functionality)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Required PRs


This comment has been minimized.

Copy link

Montellese commented Feb 11, 2018

@garbear I had a quick look at windows builds (can only test Windows 7) and on current master 42 game.libretro.* addons compiled fine whereas 26 failed (and peripheral.steamcontroller and peripheral.xarcade). So it doesn't look like it's completely broken or did I misunderstand something?


This comment has been minimized.

Copy link

Rechi commented Feb 11, 2018

@Montellese they (game addons not using msvc on windows) are not compile time broken, but runtime broken.

@garbear garbear mentioned this pull request Feb 13, 2018
@garbear garbear force-pushed the garbear:controller-topology branch from ff032ed to 1362c5d Feb 14, 2018

This comment has been minimized.

Copy link
Member Author

garbear commented Feb 14, 2018

Reports are in, and most things still work. The following input issues with cores have been identified:

These are most likely core bugs (gee, I'm shocked). In any case, I accidentally merged kodi-game/game.libretro#31 so now I gotta get this in. I'll follow up with another PR if needed.

jenkins build this please


This comment has been minimized.

Copy link
Member Author

garbear commented Feb 15, 2018

Fixes were all external to this PR. For the record, the fixes include:

@garbear garbear force-pushed the garbear:controller-topology branch from 1362c5d to e597e70 Feb 16, 2018
@garbear garbear merged commit f5871d9 into xbmc:master Feb 16, 2018
1 check failed
1 check failed
default Sorry, building this PR failed. Please check the logs for the errors.
@garbear garbear deleted the garbear:controller-topology branch Feb 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.