2015-04-17, 00:53
Hi aquiles2k,
I worked with malte in the past to beef up some api calls for RCB support. specifically, I remember allowing RCB to force a platform or game client ID when launching ROMs via RetroPlayer. ATM my branch is carrying 4 api additions, see https://github.com/garbear/xbmc/compare/......b272875 .
There is something we need for RCB to better talk with RetroPlayer: a standardized way to refer to platforms. For example, I standardized controllers using controller add-ons. All NES emulators can import game.controller.nes, so they don't have to supply controller layout/images separately. But if an add-on wishes, bundling its own controller is dead simple because an add-on can just add a second extension point.
Platform add-ons are a possibility. I don't like this idea, mostly because it duplicates info that can be scraped from http://thegamesdb.net/platforms. It also creates a LOT of add-ons. Maybe a single resource add-on that defines all platforms? If we go down this route, I'll probably convert all controller add-ons to a single controller resource add-on too.
Anyways, for the platform schema we need:
Here's a list of resources I've created so far:
I worked with malte in the past to beef up some api calls for RCB support. specifically, I remember allowing RCB to force a platform or game client ID when launching ROMs via RetroPlayer. ATM my branch is carrying 4 api additions, see https://github.com/garbear/xbmc/compare/......b272875 .
There is something we need for RCB to better talk with RetroPlayer: a standardized way to refer to platforms. For example, I standardized controllers using controller add-ons. All NES emulators can import game.controller.nes, so they don't have to supply controller layout/images separately. But if an add-on wishes, bundling its own controller is dead simple because an add-on can just add a second extension point.
Platform add-ons are a possibility. I don't like this idea, mostly because it duplicates info that can be scraped from http://thegamesdb.net/platforms. It also creates a LOT of add-ons. Maybe a single resource add-on that defines all platforms? If we go down this route, I'll probably convert all controller add-ons to a single controller resource add-on too.
Anyways, for the platform schema we need:
- Platform identifier
- Platform name (translatable)
- Possible mapping to other platform IDs like MobyGames and TheGamesDB
- Info to support my Input work: Number of ports and valid controllers for each port.
- File extensions
- Relationships (e.g. Game Boy Color supports Game Boy roms)
Here's a list of resources I've created so far:
- Kodi Platform IDs and their corresponding MobyGames ID: https://github.com/garbear/xbmc/blob/ret...ader.h#L29
- Kodi Platform ID to common name: https://github.com/garbear/xbmc/blob/ret...er.cpp#L38
- Platform file extensions: https://github.com/garbear/heimdall/blob...tem.py#L86 . This list is only for extensions with a unique platform, so multi-platform extensions like .iso and .zip are excluded.