[fetzerch]

Create depends/common/mupen64plus/windows-deps.txt with the following contents:

Code:

msys

The file should contain: mingw

[zachmorris]

...
Next, create resources/buttonmap.xml. This file maps the controller add-on to the "RetroPad" abstraction that libretro uses.
...
Create a <controller> element for each imported controller add-on. The type attribute corresponds to the libretro device type. Basically, if the controller has analog sticks, use the "analog" type. Otherwise, use the "joypad" type (as in game.libretro.genplus's buttonmap.xml)

The feature name is from the controller add-on's layout.xml.

@garbear /@fetzerch ,

Looking over this info again to try and find an automated way to build addons. I've used some of the code from kodi-game-scripting to automatically get addon and setting information. Is there some method to automatically get info on what device types and input features a core accepts (without looking directly at the source code) to help with getting buttonmap and topolgy info? Example, I see most cores have a retro_input_descriptor, but I can't understand if thats something that can be queried or not.

[garbear]

in short, no. it's hidden, and only evident in the occasional mistakes I made, but all button maps and topologies I created by crawling thousands of lines of code over several months.

that's why I created the controller topology project, to share the data I gathered from source code without having to upstream much complexity to a hundred emulator repos. the data is not accessible because it's in Kodi format, but if you want to use it I can translate everything to json-ld.

I can also crawl code for you (it's become a masochistic pleasure) if you need additional data. though time is tight so I'd appreciate contributions too.

[zachmorris]

in short, no. it's hidden, and only evident in the occasional mistakes I made, but all button maps and topologies I created by crawling thousands of lines of code over several months.

that's why I created the controller topology project, to share the data I gathered from source code without having to upstream much complexity to a hundred emulator repos. the data is not accessible because it's in Kodi format, but if you want to use it I can translate everything to json-ld.

I can also crawl code for you (it's become a masochistic pleasure) if you need additional data. though time is tight so I'd appreciate contributions too.

Thanks for this info. For the default controllers you don't already have covered, it seems like the default controller should work 99% of the time anyway. I did have a few questions:
If a buttonmap includes two or more buttonmaps / topologies per port, how does Retroplayer decide which one is being used?
Example would be Saturn:

xml:


<port id="1">

    <accepts controller="game.controller.saturn"/>

    <accepts controller="game.controller.saturn.3d"/>

    <accepts controller="game.controller.saturn.multitap">

      <port id="1">

        <accepts controller="game.controller.saturn" type="RETRO_DEVICE_JOYPAD" subclass="0"/>

        <accepts controller="game.controller.saturn.3d" type="RETRO_DEVICE_ANALOG" subclass="0"/>

      </port>

If I were to submit some more buttonmappings/controller for say arcade controllers (see some variants here), how would Retroplayer / Kodi then decide which one is being used when using that game addon?

[garbear]

RetroPlayer uses the first controller accepted by the port. The goal of the unfinished player manager was to allow the user to choose additional controllers.

[rockbox948]

Is this still the methodology for adding cores like Mupen64Plus?

[RockerC]

Is this still the methodology for adding cores like Mupen64Plus?

It still looks so, or? @garbear

https://kodi.wiki/view/Porting_Libretro_...me_add-ons

https://kodi.wiki/view/Game_development

https://kodi.wiki/view/Libretro

FYI, Mupen64Plus-Next, ParaLLEl N64, and ParaLLeXT are Nintendo 64 (N4) emulators that look to have already been ported to Kodi Game API, see:

https://github.com/kodi-game/game.libret...n64plus-nx

https://github.com/kodi-game/game.libretro.parallel_n64

https://github.com/kodi-game/game.libretro.parallext

You can however not play those due to lack of GPU rendering for 3D graphics hardware acceleration (OpenGL, OpenGL ES, DirectX, Vulkan, etc.), see:

https://forum.kodi.tv/showthread.php?tid=351592

https://forum.kodi.tv/showthread.php?tid=205571

https://forum.kodi.tv/showthread.php?tid=366438

https://forum.kodi.tv/showthread.php?tid=354031

https://forum.kodi.tv/showthread.php?tid=231651

https://forum.kodi.tv/showthread.php?tid=339480