[garbear]

you'll notice the only functional difference is that RetroPlayer is no longer connected to any input. I've re-written the joystick API two or three times, and the end result was never satisfactory because I couldn't separate the input from retroplayer. now, with input gone, the complexity of retroplayer is greatly reduced, leading to more maintainable code.

putting as much code as possible behind APIs is generally a good strategy. i learned this rather late in the development of retroplayer, so there are still quite a few parts that are entangled. however, looking at this diagram, i think i'm on the right track - components are finally only communicating with their API, and not with other components

[zag]

Great to see things progressing

I was worried this might not get in due to the sheer scale of it. Anything that makes it simpler and more maintainable is a great thing.

[ChrisMyhre]

Thanks for the update and keep up the good work. I agree that anything that simplifies the core functionality and gets this into mainline sooner is a great thing for future progress.

[Hedda]

little update on how retroplayer fits in with XBMC:



this is the current layout of the retroplayer project. it is centered around two APIs, the Game API (connects retroplayer to game clients) and the Hardware API (connects game clients to input). the Hardware API moves all of the joystick code out of XBMC and into binary add-ons. i have also started working on support for the Retrode and retrode-like devices through the media reader sub-API.

you'll notice the only functional difference is that RetroPlayer is no longer connected to any input. I've re-written the joystick API two or three times, and the end result was never satisfactory because I couldn't separate the input from retroplayer. now, with input gone, the complexity of retroplayer is greatly reduced, leading to more maintainable code.

putting as much code as possible behind APIs is generally a good strategy. i learned this rather late in the development of retroplayer, so there are still quite a few parts that are entangled. however, looking at this diagram, i think i'm on the right track - components are finally only communicating with their API, and not with other components

This all sounds great!

Hope this API strategy will also help simplify future extensions for networked / online gaming such as RakNet integration could offer?
http://forum.xbmc.org/showthread.php?tid=201868

Love the interface concept behind the Ignition project with a community lobby-system for friend chats and leaderboard ranking
http://forum.xbmc.org/showthread.php?tid=202061

[Scr3wdriv3r]

If this is to become a integrated thing in XBMC, would that mean it runs on everything that runs XBMC?

Reason I ask is because I recently bought a Pivos XIOS XS, that ran on Android, but I turned to this version from Hydra and would love the possibility to play games on XBMC, but I am not sure if Retroplayer is already capable on ARM.

XBMC Linux Firmware Release #: the-hydra-xbmc-Linux-XIOS-XS-gotham-13-2-mk2-20141017
Revision Date: 20141017 - Feature Linux MX 3.0.101 kernel

Would similar but future versions of such builds have this integrated as well (just recently started using XBMC/Kodi)?

[garbear]

If this is to become a integrated thing in XBMC, would that mean it runs on everything that runs XBMC?

Reason I ask is because I recently bought a Pivos XIOS XS, that ran on Android, but I turned to this version from Hydra and would love the possibility to play games on XBMC, but I am not sure if Retroplayer is already capable on ARM.

XBMC Linux Firmware Release #: the-hydra-xbmc-Linux-XIOS-XS-gotham-13-2-mk2-20141017
Revision Date: 20141017 - Feature Linux MX 3.0.101 kernel

Would similar but future versions of such builds have this integrated as well (just recently started using XBMC/Kodi)?

Yes, retroplayer will run on everything that XBMC supports. through no actions of my own, i have become the owner of many, many ARM devices. being an xbmc developer has its perks.

universal ARM support is on my list of Things To Do, but below some more critical parts like not-sucky input. when I get around to ARM support, i'll be testing on the following devices:

• pivos XIOS DS
  
• NVidia Shield
  
• RPi
  
• a box I can't talk about
  
• possibly beagleboard
  

OSX support is in the works. I'm actually developing on windows, linux and mac in parallel now, using git to sync everything, so future releases will be simultaneous across all three platforms

[eltriste713]

I look forward to the day i get my hands on an official release of Retroplayer ! Keep up the good work and keep it coming.

[braz]

What is the relationship between RetroPlayer and Rom Collection Browser? Will RCB become unnecessary once RetroPlayer is released? I only ask because I am thinking of skinning RCB for my local Windows games, but am willing to wait if RetroPlayer will include this same functionality. Thanks!

[chapas]

little update on how retroplayer fits in with XBMC:






this is the current layout of the retroplayer project. it is centered around two APIs, the Game API (connects retroplayer to game clients) and the Hardware API (connects game clients to input). the Hardware API moves all of the joystick code out of XBMC and into binary add-ons. i have also started working on support for the Retrode and retrode-like devices through the media reader sub-API.

@garbear does this still holds in the Kodi 20.1.0-Nexus?

[garbear]

little update on how retroplayer fits in with XBMC:






this is the current layout of the retroplayer project. it is centered around two APIs, the Game API (connects retroplayer to game clients) and the Hardware API (connects game clients to input). the Hardware API moves all of the joystick code out of XBMC and into binary add-ons. i have also started working on support for the Retrode and retrode-like devices through the media reader sub-API.

@garbear does this still holds in the Kodi 20.1.0-Nexus?

Surprisingly this design has held up quite well. The biggest difference is I never developed the Hardware API past input devices.

The other notable change, not reflected in the diagram, is that the big "RetroPlayer" box has been entirely rewritten from scratch to support shaders in GSoC 2017.

[RockerC]

@garbear suggest you get a moderator to move this from support forum to https://forum.kodi.tv/forumdisplay.php?fid=243 or https://forum.kodi.tv/forumdisplay.php?fid=194

[garbear]

@garbear suggest you get a moderator to move this from support forum to https://forum.kodi.tv/forumdisplay.php?fid=243 or https://forum.kodi.tv/forumdisplay.php?fid=194

Thanks for the advice, I moved the thread to the Documentation section.

[RockerC]

@garbear perhaps you could get someone to update this XBMC Architecture Overview Schematic on Wikipedia as well:

https://commons.wikimedia.org/wiki/File:...ematic.png

That is used in the Architecture section for the Kodi article on Wikipedia article: 

https://en.wikipedia.org/wiki/Kodi_(soft...chitecture

It would probably also be a good idea to have that in Kodi's xbmc/xbmc repo and shown in a file under docs? Maybe:

https://github.com/xbmc/xbmc/blob/master/docs/README.md

or 

https://github.com/xbmc/xbmc/blob/master...IBUTING.md

IMHO it would be nice if one of those README files had written architectural design summary for developers there too.