-
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.
The easiest thing to do, is just remove the system/console using the Rom Collection Browser context menu.
There are a lot of version good reasons for this. Primary, some emulators don't seem to allow you to "preset" you controller config within an ini file before starting (even with profiles). Furthermore, some presets do not exist to make the entire process "gamepad friendly," but that has largely been solved by including Antimicro control profiles in RCB's XML code.
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 meant 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 takes 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
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.