GSOC20 Multiple Controllers
#16
Hello @garbear ,
Actually I ran into another problem while running make-mingwlibs.bat file. It now says that it can't find any openssl file and/or any makefile.
Here is the log file for the error.

Mainak
Reply
#17
ERROR: openssl not found

It looks like openssl wasn't downloaded by the download build deps step.

At this point I usually backup the downloads folder, do a git clean -xdf, then restore the cached downloads and start from the beginning
Reply
#18
(2020-03-22, 15:10)garbear Wrote: ERROR: openssl not found

It looks like openssl wasn't downloaded by the download build deps step.

At this point I usually backup the downloads folder, do a git clean -xdf, then restore the cached downloads and start from the beginning

Thank you this worked for me

Also I got how the different topologies are precoded into Kodi and understood thos that you gave. So now I am proceeding over to peripheral.joystick code to understand the lifecycle of a button press and the code part of button mapping.

This may take a while. Also stay safe Smile .

Regards,
Mainak
Reply
#19
Traversing the code is not a trivial task (ref above). Each vertical group of nodes is an API. The APIs are layered on each other, so you end up with a data flow where the data is transformed at each layer:

1. Starting with operating system APIs
2. Next to joystick driver input in C++ (peripheral.joystick)
3. Converted to C for the binary add-on API
4. Converted back to C++ immediately in Kodi

The data flow is a graph, because you'll notice the presence of nodes, the first being the peripheral add-on (CPeripheralJoystick). You can identify nodes in the code when, instead of a handler, they have a std::vector<handler> and a for loop.

5. At this point in the xbmc/peripherals code, we have driver input (low-level). Each handler in the for loop gets this data, and most transform it to controller input (high-level) using a button map. Each driver input handler can use a different button map, and they can be all be different button maps. Thus, input handlers "request" data in whatever form they want, and a lower layer translates driver input to make it look like that controller's input.

An exception is driver input handlers that operate on raw driver data, such as the button mapper.

6. & 7. From the controller input level, you can see there are still many layers (notice all red boxes have two columns of nodes).

7. - X. Traveling down the "Libretro Core" path, there are still many layers to cross. Not shown in the two binary add-on layers, where data is marshaled to C and back again.
(2020-03-23, 18:52)cool-pants Wrote: This may take a while. Also stay safe Smile .

I'm hunkered down in san francisco. my life: 1. stay home, 2. while (1) { code() };
Reply
#20
Sorry to overload this thread with info, but I'm hoping to collect and formalize for documentation later.

Graphs

Back to graph theory, here's some description of the data flow in the above API layers.

The data at each stage in the flow chart is stored in a tuple (struct). The tuple represents stuff on the controller, and each thing is a node in a graph. In this case, the graph is a fully unconnected graph, because we don't care about how the data is related within the layer.

Transformations

API layers transform the tuple into another tuple. You can visualize this by putting two controller representations side by side, and drawing lines between things on each controller. When you have a group of nodes on one side, and another group on the other side, with lines between them, this is called a bipartite graph.

If translation happens in one direction, this would be a directed graph. It would likely be a bijection, where one thing is mapped to one other thing. It can also be a surjection, where two things are mapped to one thing. For example, I'm working on surjective button mapping, where both a dpad and analog stick can control a single dpad in libretro.

I challenge you to think of how button mapping can be an injection Smile
Reply
#21
Topology

The subject of topology refers to studying how things are connected. If you've ridden the subway, you've seen a topological map. This shows how stations are connected, but isn't accurate geographically. It contrasts with a topographical map, which shows accurate geography like trails and mountains.

Primarily, in emulation, we study two different kinds of topology:

 
  • Button topology: how buttons map from one controller representation to another
  • Wire topology: how controllers are physically connected with wires

An aside: The human perception

I'll share a story from school. I was studying thermodynamics, particularly the problem of how heat moves through a solid object. In three dimensions this yields some pretty unwieldy partial different equations!

Fortunately, there's another approach. We can use a computer to divide the solid into small parts, and compute how heat spreads from part to part. In general, the smaller the parts, the more accurate the result. This computer approach is called Finite Element Analysis (FEA).

Now, there's two main FEA algorithms:
 
  • One is more accurate, but can diverge and never give a result
  • One is less accurate, but always gives a result

Which do you think FEA software makers use?

The answer is the second, because there's only one thing worse than a wrong result: no result. This drives my study of topology, because the only thing worse than swapped buttons: no buttons. We can use topology to choose a good-enough map for unseen controllers.
Reply
#22
Practical application in Kodi

With tolopogy you can start doing some pretty smart things. For example, if tuples are used for points of data at the driver level, we can count the number of buttons, hats and axes. If this exactly matches another tuple's counts, then it's a good-enough assumption that buttons on both controllers are in the same spot and can use the same map.

Mapping physical controllers to virtual controllers to libretro controllers is an N * M * O problem, because we have:

 
  • Large N physical controllers
  • Large M virtual controllers
  • Large O libretro controllers
  •  N * M * O possible transformations


It's impossible to store N * M maps, let alone N * M * O. Instead, we store this data:

 
  • Maps of all physical controllers to one virtual controller (peripheral.joystick maps)
  • A single map of one physical controller to all virtual controllers (this one)


Now, using a graph transformation, we can map all physical controllers to all emulated controllers.

We also store this data:

 
  • A map of several virtual controllers to several libretro controllers (e.g. this one)
  • One such map for all emulators


Apply another graph transformation, and you can map N controllers to M controllers to O controllers, for N * M * O possible mappings.

With topology, we can also view that mockup in a new way. Notice the depth-first player assignment. Players are assigned to controllers with input, and multitaps are skipped. Also notice that we've performed the difficult task of visualizing a tree in a two-dimensional grid. This is called a tree-drawing algorithm. All tree operations are performed recursively, which ramps up the difficulty, but scales to handle weird configurations, like daisy-chaining (hubs with input).

Image
Reply
#23
(2020-03-23, 21:22)garbear Wrote: I challenge you to think of how button mapping can be an injection Smile

Well it makes sense for button mapping to be an Injection or One-to-one function as we only need a single button on the physical controller to be mapped to only one subsequent button on the emulated one. Otherwise the whole operation would be chaos. Imagine mapping the A button to be both select and back, which will be confusing both to us and the device as one input is trying to do two opposite operations simultaneously. This is only one of the examples. So, well the button mapping should, or rather, must be injective. Also, though not asked, it could also be surjective or onto, which implies that all the buttons on the virtual emulator must be mapped, which also makes sense as the buttons on a controller are there to be used and an unmapped button will mean that you can't use the function attached to that button in-game. But there also is the option of not mapping surjectively, but it should definitely be injective.

PS: also i talked only about the Physical and Kodi controller interaction, but this will also apply for the Kodi-RetroPad controller interactions.
Reply
#24
Also this is my edited proposal with much of the edits you specified before and the knowledge i gained from further studying the code and the resources you provided.

Proposal.
Reply
#25
I like how the summary is the two mappings we'll have to consider. Motivation, Benefits and Goals are clear and easy to read. Good use of links. Very relevant experience. It's a strong proposal.
Reply
#26
To be honest, I think "Multiplayer", while being synonymous with "Multiple controllers", sounds more impressive and brings better bragging rights, don't you? That said, it's your project, and I'll support whatever name you want the most.
Reply
#27
(2020-03-25, 17:24)garbear Wrote: To be honest, I think "Multiplayer", while being synonymous with "Multiple controllers", sounds more impressive and brings better bragging rights, don't you? That said, it's your project, and I'll support whatever name you want the most.
Well yeah Multiplayer does sound pretty amazing and that's the heading I chose for my proposal. I started with the latter as a header to not sound pretentious and tried to keep it as humble as possible but now I switched to "Multiplayer".
Reply
 
Thread Rating:
  • 0 Vote(s) - 0 Average



Logout Mark Read Team Forum Stats Members Help
GSOC20 Multiple Controllers00
This forum uses Lukasz Tkacz MyBB addons.