(2015-04-13, 23:10)garbear Wrote: [ -> ]...
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.
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.
(2019-07-26, 22:56)garbear Wrote: [ -> ]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?
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.
Is this still the methodology for adding cores like Mupen64Plus?
(2022-01-18, 05:59)rockbox948 Wrote: [ -> ]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