[garbear]

1. What is blocking the current implementation of save states from being merged upstream? It would be nice to have it in Nexus.

I'm working on this with @NikosSiak as we speak. We're migrating the rcheevos library from version 9 to version 10, which requires some additional work. After that we'll merge the GSoC PR into my repo, rebase on master, and then open the PR upstream.

That will also unblock @Shardul from PRing the achievements work he did over last summer.
 

2. I was missing an icon for Picodrive, so I've quickly created one for myself. If it meets the requirements, feel free to use it for the add-on:
http://koprajs.mx-net.cz/icon.png

Great! So far most of the icons and descriptions for emulators and controllers I did myself, which took a *lot* of time but it only has to be done once. I appreciate all contributions, and don't stop if you want to make more icons!

A PR on github is preferable, but if you don't want to figure that out, bring any and all artwork here and I'll make sure it gets in the right place.

[garbear]

I typed this up yesterday, computer crashed but somehow it survived. Here's my idea for what data storage for player profiles would look like. Sounds like we won't do player profiles yet but I'll upload it now to reference later.
 

Code:

<?xml version="1.0" ?>
<!-- Outer tag -->
<players>
  <!-- Tag per player -->
  <player id="did:example:123456789abcdefghi">
    <!-- Stores the player's default buttonmaps -->
    <buttonmaps>
      <buttonmap>
        <device name="Xbox 360-compatible controller" provider="xinput" buttoncount="15" axiscount="6">
          <controller id="game.controller.saturn">
            <feature name="a" button="0" />
            <feature name="b" button="1" />
            <feature name="c" button="5" />
            <feature name="down" button="12" />
            <feature name="left" button="13" />
            <feature name="leftbumper" axis="+4" />
            <feature name="right" button="11" />
            <feature name="rightbumper" axis="+5" />
            <feature name="start" button="7" />
            <feature name="up" button="10" />
            <feature name="x" button="2" />
            <feature name="y" button="3" />
            <feature name="z" button="4" />
          </controller>
        </device>
      </buttonmap>
    </buttonmaps>
    <!-- Stores the player's port config and per-port buttonmaps -->
    <gameclients>
      <gameclient id="game.libretro.yabause"/>
        <!-- Port definitions -->
        <ports>
          <!-- Port 1 definition, multitap connected -->
          <port id="1" address="/1" connected="true" controller="game.controller.saturn.multitap">
            <!-- Port-specific buttonmap for Saturn controller, when it is re-connected -->
            <controller id="game.controller.saturn">
              <buttonmap>
                <device name="Xbox 360-compatible controller" provider="xinput" buttoncount="15" axiscount="6">
                  <feature name="down" button="12" />
                  <feature name="left" button="13" />
                  <feature name="right" button="11" />
                  <feature name="up" button="10" />
                </device>
              </buttonmap>
            </controller>
            <!-- Multitap configuration -->
            <controller id="game.controller.saturn.multitap">
              <!-- Multitap port 1 is connected to a saturn controller -->
              <port id="1" address="/1/game.controller.saturn.multitap/1" connected="true" controller="game.controller.saturn">
                <!-- Here's the per-port specific button map -->
                <controller id="game.controller.saturn">
                  <buttonmap>
                    <device name="Xbox 360-compatible controller" provider="xinput" buttoncount="15" axiscount="6">
                      <feature name="a" button="1" />
                      <feature name="b" button="0" />
                      <feature name="c" button="2" />
                      <feature name="x" button="5" />
                      <feature name="y" button="4" />
                      <feature name="z" button="3" />
                    </device>
                  </buttonmap>
                </controller>
              </port>
              <port id="2" address="/1/game.controller.saturn.multitap/2" connected="true" controller="game.controller.saturn" />
              <port id="3" address="/1/game.controller.saturn.multitap/3" connected="true" controller="game.controller.saturn" />
              <port id="4" address="/1/game.controller.saturn.multitap/4" connected="true" controller="game.controller.saturn" />
              <port id="5" address="/1/game.controller.saturn.multitap/5" connected="true" controller="game.controller.saturn" />
              <port id="6" address="/1/game.controller.saturn.multitap/6" connected="true" controller="game.controller.saturn" />
            </controller>
          </port>
          <port id="2" address="/2" connected="true" controller="game.controller.saturn.multitap">
            <controller id="game.controller.saturn.multitap">
              <port id="1" address="/2/game.controller.saturn.multitap/1" connected="true" controller="game.controller.saturn" />
              <port id="2" address="/2/game.controller.saturn.multitap/2" connected="true" controller="game.controller.saturn" />
              <port id="3" address="/2/game.controller.saturn.multitap/3" connected="true" controller="game.controller.saturn" />
              <port id="4" address="/2/game.controller.saturn.multitap/4" connected="true" controller="game.controller.saturn" />
              <port id="5" address="/2/game.controller.saturn.multitap/5" connected="true" controller="game.controller.saturn" />
              <port id="6" address="/2/game.controller.saturn.multitap/6" connected="true" controller="game.controller.saturn" />
            </controller>
          </port>
        </ports>
    </gameclients>
  </player>
</players>

[KOPRajs]

A PR on github is preferable, but if you don't want to figure that out, bring any and all artwork here and I'll make sure it gets in the right place.

I can create the PR if needed but it seems a little over-complicated to fork the repo just to add an icon. So I'd prefer if you can look at the icon first and then add it directly, if you like it.

The icon is a transparent PNG in 256x256 just like the other game add-ons icons:
http://koprajs.mx-net.cz/icon.png

EDIT:
Inspired by the Genplus icon:
https://raw.githubusercontent.com/kodi-g...s/icon.png

EDIT2:
The device on the photo is the Sega Genesis with both the Sega CD and the Sega 32X add-ons (since Picodrive is the only emulator that is able to emulate the 32X). The logo is official from Picodrive and the photo is from Wikipedia, if there is any copyright concern.

[garbear]

I can create the PR if needed but it seems a little over-complicated to fork the repo just to add an icon.

That's kinda how things are built these days. Pretty much everything in Team Kodi's ecosystem that touches GitHub is done by PR. The learning curve is kinda steep, which is why I'm offering to do the PR for you. But it's also kinda satisfying to learn the tools for collaborating in the code community.
 

The logo is official from Picodrive and the photo is from Wikipedia, if there is any copyright concern.

This is handled by a <disclaimer> tag in addon.xml. See how it's done: https://github.com/kodi-game/game.libret...xml.in#L31
 

EDIT:
Possible configuration for DOSbox:

I change the vertical list from players to peripherals. Here's how it looks for DOSBox now, after changing the 4-player joystick to the two 2-player joysticks:





The idea is that a "peripheral" list could be used for both ports and player profiles. Instead of horizontal "Ports" you'd have horizontal "Players".

Also of note is the length of controller driver names. I've seen driver names about 1.5x the length of the "Xbox 360-compatible controller" name.

 

- We can even show the keyboard line only if there is a keyboard port available. This way we don't need the keyboard and mouse on/off switches in settings anymore.

Eventually I'll detect whether to show the mouse and keyboard peripherals if input arrived from the peripheral since Kodi was started. That way, starting on a touchscreen or NVidia Shield won't show keyboard/mouse. If a keyboard was connected, but a key press is just now occurring, then it'll be like plugging in a keyboard and the keyboard peripheral will appear in the GUI (same for mouse input).

 

- I do not consider supporting more than 1 keyboard and 1 mouse. I'm not sure if it would be even possible on all platforms.

We only have one keyboard port and one mouse port. It's possible to expose multiple keyboards to the emulator, using controller ports that only accept a keyboard. However, then I guess you'd call the keyboards controllers.

Keyboard/mouse/controller is specifically a port type abstraction used in topology.xml. The emulator sees a single keyboard port, a single mouse port, and multiple controller ports. This is the level where keyboards are considered controllers. It's important because that's how the horizontal port list is formed - first a virtual keyboard port (if a keyboard appears in topology.xml), then then a virtual mouse port (if a mouse appears in topology.xml), then the controller ports in order of ID as they appear in topology.xml.

Kodi has similar peripheral logic when building the vertical peripherals list. If a key has been pressed since startup, then a keyboard appears connected. Same for mouse. Then the controller peripherals in Operating System order.

[garbear]

Here's another illustration, this time of Amstrad CPC.

Here's the port list, showing the keyboard port, followed by the mouse port, followed by controller ports in order of ID, as defined by topology.xml:



Here's the player manager (needs to be renamed):

[KOPRajs]

Eventually I'll detect whether to show the mouse and keyboard peripherals if input arrived from the peripheral since Kodi was started. That way, starting on a touchscreen or NVidia Shield won't show keyboard/mouse. If a keyboard was connected, but a key press is just now occurring, then it'll be like plugging in a keyboard and the keyboard peripheral will appear in the GUI (same for mouse input).

That is right, but it is not what I meant. The idea was to also do not show the keyboard if there is no "emulator port" for the keyboard available. Or maybe a better explanation: To show the keyboard only for emulators that actually support keyboard in their topology.xml and have it enabled in the Port Setup. The motivation is to reduce confusion of users trying to assign the keyboard to a controller ports in the SNES, Genesis etc.

 

We only have one keyboard port and one mouse port. It's possible to expose multiple keyboards to the emulator, using controller ports that only accept a keyboard.

I meant multiple physical keyboards. I believe that even if you connect 2 physical keyboards to a device, most operating systems will still expose only one keyboard. You can type on both of them, but they are going to behave like one. Hence there is no need to support more than one in the Controller manager.

 

That's kinda how things are built these days. Pretty much everything in Team Kodi's ecosystem that touches GitHub is done by PR.

I've created PRs before, I'm just lazy. I'll create the PR for the icon.

P.S. Congratulations for the Savestate manager PR!

[garbear]

The motivation is to reduce confusion of users trying to assign the keyboard to a controller ports in the SNES, Genesis etc.

I agree that confusion occurs if users can't assign a keyboard to controller ports. We *could* hide the keyboard, but my counter offer: we finally allow keyboards to be assigned to controller ports. I'm thinking we always show the keyboard (assuming a key has been pressed since startup) because users can use a keyboard for controllers universally.

We'll need to make a change to the button mapper. It has to show which keys are bound to each button. It's fine to have a user hunt down unknown buttons on a controller, because it's expected where most buttons would be, and trial-and-error is quick for the rest of the buttons.

On the other hand, there's no expectation what keys are which buttons, so we'll have to show key bindings. The cool thing is, the code to show key bindings is the same to show controller bindings for all buttons, so we get that feature as well.

I meant multiple physical keyboards. I believe that even if you connect 2 physical keyboards to a device, most operating systems will still expose only one keyboard. You can type on both of them, but they are going to behave like one. Hence there is no need to support more than one in the Controller manager.

Exactly. The key is the "operating system" part. We're limited by OSes combining all key presses, so we have no choice, keys (and mice) are always "multiplexed". Controllers are the only thing OSes can distinguish between.

However, there's an exception - the Xarcade Tankstick driver I wrote and use to this day. It hooks into udev and intercepts the keyboard presses from the Tankstick, and de-multiplexes input to create two physical controllers in the vertical list. But of course this only works on Linux and udev, making it kinda limited. I'll come back with a picture of how it looks with my Tankstick connected.

[garbear]

I made more progress. The controllers now actually show which port they're connected to.


Configured Saturn with two 6-player multitaps. Connected four Xbox controllers:





Changed multitaps back to two Saturn controllers:





I guess next I implement moving left and right.

[garbear]

Here's my idea for player profiles





The QR code encodes the address kodi-game.github.io and three parameters:

 

• Local IP addresses, for when Kodi and the mobile device are on the same LAN
  
• STUN IP address, for when Kodi is behind an asymmetric NAT (home router)
  
• Twilio TURN media relay, for when Kodi is behind a symmetric NAT (mobile connection)
  

When the user scans the QR code with their phone, it launches kodi-game.github.io. The client website hosted there (like a simple React app, or even framework-less javascript) tries to connect to Kodi via WebRTC using these three parameters.

When a direct WebRTC connection is formed, the website and Kodi can communicate. The website can offer any number of SSO services, like "Login with Google" or "Login with Discord" or "Login with Dropbox". The website sends the credentials to Kodi, allowing Kodi to use these services as the user.

If the user logs in with Discord, then our Rick Presence captions can be shown in their Discord status.

If the user logs in with Dropbox, then savestates can be stored to the account.

Google can also probably be used to store savestates, though I don't see a C++ API for Google Drive.

We can also link to RetroAchievements and send the username/password to Kodi so that Kodi can automatically log in to RA.

Twilio is a paid service, but they change < $1 per GB, and we just pass credentials over the wire then that's like a coffee a month.

[garbear]

Here's my idea for managing universal player identities:





I've added a new type of binary add-on: "Identity providers" or "Identity drivers". These add-ons can securely store player identities. They are universal, which means your identity follows you on any device you connect. That's probably the coolest part.

I plan to offer two drivers, one that persists identity on GitHub (using libgit2), the other that persists identity on IPFS (using libp2p).

To use the GH driver, Kodi will show a QR code that you can scan with a small web app at https://kodi-game.github.io . You can then link Kodi to your GH account, and store your identity in a github repo.

The IPFS is a "just works" driver. Your identity is stored on IPFS and follows you wherever you go. This will be the default until GH is linked.

The way identity follows you is that Kodi generates a "DID" - a decentralized ID. For GH accounts, this looks like did:github:garbear. For IPFS, this looks like did:ipid:QmPK1s3pNYLi9ERiq3BDxKa4XosgWwFRQUydHUtz4YgpqB. The DID is fully decentralized. You take it with you forever, and it can be used to log in to any web3 service. When Microsoft's DID portal is up, then you can even log into Microsoft with a DID generated on your Kodi device, and your identity will follow you to MS's service.

I should be able to store all user data inside the DID as well, so you just need to move your DID string to a new Kodi instance and all yours saves will come with you.

[zachmorris]

This sounds pretty cool. Looking forward to trying it out. Seems like a great starting method to integrate netplay somehow.

[Wintermute0110]

@garbear Thank you very much for your work on this. Multi-joystick support in Kodi was a long awaited feature. I am pretty busy with RL at the moment but will have a look ASAP.

[KOPRajs]

Hi,
somehow I missed a lot of news here.
 

I agree that confusion occurs if users can't assign a keyboard to controller ports. We *could* hide the keyboard, but my counter offer: we finally allow keyboards to be assigned to controller ports. I'm thinking we always show the keyboard (assuming a key has been pressed since startup) because users can use a keyboard for controllers universally.

I think the emulated keyboard controllers would be a better option for using keyboard in the controllers only games. In that case the real keyboard should be only shown if there is real keyboard support to avoid confusion.

The idea is:
1. You add a virtual Gamepad 1.
2. You map the keyboard keys to a virtual Gamepad 1 buttons using the existing button map dialog.
3. The virtual Gamepad 1 is shown in the controller manager and can be assigned to the controller ports (maybe using a regular gamepad icon with a little keyboard icon in the bottom corner?).

This way you can easily add even more virtual gamepads and assign different keys from the same keyboard to them.

Also of note is the length of controller driver names. I've seen driver names about 1.5x the length of the "Xbox 360-compatible controller" name.

We can simply truncate them and make them scrolling when focused with the blue row. This is a regular Kodi behavior when a text is too long to fit in.

[KOPRajs]

This is how I imagine the typical keyboard only setup:

[garbear]

Hi,
somehow I missed a lot of news here.

The GUI is unchanged since you last visited. My muse was missing So instead, I've made a lot of progress on DID - decentralized identities that follow the user, even can even be used to log into external services.



Local Keystore is implemented so I have something to play with. I'm about halfway done with IPFS.

The idea is:
1. You add a virtual Gamepad 1.
2. You map the keyboard keys to a virtual Gamepad 1 buttons using the existing button map dialog.
3. The virtual Gamepad 1 is shown in the controller manager and can be assigned to the controller ports (maybe using a regular gamepad icon with a little keyboard icon in the bottom corner?).

I think I understand. So there would be two dialogs, one for players (or would it be physical controllers?) and one for virtual controllers.

Players:



Virtual controllers: