-
Notifications
You must be signed in to change notification settings - Fork 12
- Why do I have to have so many systems in the RCB list?
- [Why isn't X console supported?] (#unsupported)
- When will feature X come out?
- Why don't I just load XBMC+RCB myself?
- Should I use branch X over the master branch?
The plan was, in the past, to maintain an eventual "core" of 15 or so systems in the list. This is still undecided on if this will be a "core set" with the option in the settings to "expand all systems," or simply instruct users to delete the ROM collections they don't want to see (which is incredibly easy). This also hinges on some unfinished RCB support in the Maximinimalism XBMC skin the project uses as well.
There are a lot of version good reasons for this. Primary, some emulators, such as Dolphin, don't seem to allow you to "preset" you controller config within an ini file before starting (even with profiles). No text editor I tried seemed to make a difference, so it wasn't a "ASCII format" issues or some sort. It seems the only way to set the profiles, is via the GUI. Until problems like this get sorted out, or ever, I will not include the emulator by default, even though it's quite possible to use it (with a keyboard and mouse to set things to the gamepad).
Until things kinda stabilize and I can try out neat ideas to make this bigger than what it is now, features are added when time allows. You're always welcome to submit a feature request in the issues section at any time.
RetroRig is meat solely to provide an easy base for retro gaming to work from. Everyone has their opinion of what an ideal solution is. For some, RetroArch+Emulation Station is what they love, and for me XBMC, and the slick sorting options of Rom Collection Browser is my thing. Being able to also use XBMC for a myriad of other things is a plus for me as well. I started this for myself, so any benefit another person gets is a plus, and anyone that doesn't care for this, that is completely fine. The springboard RetroRig supplies take a lot of time and frustration out of the typical manual equation of setting this all up for yourself.
There currently are 3 branches:
* master - "stable" (as much as I can I suppose)
* beta - "test bed" for changes to merge into master
* vbox-beta - branch for beta vbox implementation
The master branch is considered "stable," where as the "beta" branch is where I stage upcoming changes I need to test out first. The "vbox-beta" branch is where early testing occurs for VirtualBox users, which is a tricky area to tackle at times (with graphics support and USB host issues). There is a non listed branch called "testing," where I just play around with random things, and really shouldn't be used by anyone.