Join GitHub today
Controller topology (multitap support) #13499
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.
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
@garbear I had a quick look at windows builds (can only test Windows 7) and on current master 42
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
Fixes were all external to this PR. For the record, the fixes include: