It’s one to discus as I’m not sure it fits the “Dev” theme of bounties but to me documentation is not seen as very gocci And may need some incentive to get done properly

I have come across so many bits of information by accident that just gets buried in the forums. I will help this project for free if there is some guidance/checklist to follow.

The git hub page is missing a compile for Android guide and from last check there’s only one core that’s been covered.

Maybe some low short level tips or faq answers could be a way to ease in. Idk please discuss


I would contribute a few dollars to a bounty regarding documentation.

For bounty purposes I agree it would be important to come up with a few specific types of needed docs like you said with your Android or FAQ examples.


There actually is a bounty for core documentation that has been posted:


I’ve already done the majority of documentation for retropie, so what’s another project? I’ll give it a go, we have a lot of the info already on our docs so it’s just a matter of picking a template and parsing out the data and adding relevant RetroArch specific data.

Might be good to get some feedback on the retropad stuff too, we set up diagrams with controllers which were supposed to match up with the core configuration but they also overlap with emulationstation stylewise, but I know the RetroArch wiki has basic charts. Not sure what the preference would be for the new docs


Great to have someone with some experience tackling this one I personally think RetroPi docuentations is very good

Im happy to help out wherever I can no bounty needed for me btw.

I would suggest for the controller stuff the format on this doc would be a good start with a full size image at the start for easy reference. I can see about sourcing HQ controller pics.


Think I’m going to port this page As my 1st attempt at adding to docs

@hunterk or @radius do you guys know if there is a HQ retropad image anywhere?


@Herb_fargus where is the 3do image stored? I am trying to do Yabause core port. Not sure how that link works.


I pulled it from the RetroPie wiki:

I was being lazy so as a bit of a hack I uploaded the images to GitHub on an issue tracker and use the generated links as the permalink in the wiki pages.


Ok cool, I will keep adding the images to the folder structure as I have done.

I missed the Saturn page on there will go back over that.

Do you have a idea of the pages your adding? As didn’t want to work on same ones


Might be worth making a Google doc or something with a list of all the cores just to keep track (and I mean working cores that would show up under stable RetroArch builds, I don’t want to crap it up with broken or unfinished cores)

Also maybe would be good to come up with a naming convention for files. Was thinking of using the core name for images so eg:

Banner: Stella_banner.png Joypad: Stella_joypad.png

And then for the actual pagination on the docs (in mkdocs.yml) we use the display name which is the system and core name and preferably I’d like to have them be in alphabetical order so they match the order we see in the core list within retroarch:

Atari 2600 (Stella)

Also as part of the Google doc to mention what’s incomplete or what needs to be verified, and we can maybe tag the ones we are working on so we aren’t duplicating work


Agreed with all of the above

Whipped up a blank doc just need gmail address to add people

I was also thinking of adding a warning like the main page has for things like Jaguar emulation being poor generally.

Planning on using conditional formatting with a colour code noted in column heading and key for quick reference


I requested access. I think I’ll compile the banners and diagram assets just so they are there.

and of course just in case you aren’t aware the majority of the docs info can be parsed from the libretro super repo:

If we were really ambitious we would just have a realtime database parser that generates the docs based on the super repo. We did a similar thing for the retropie docs where we have a basic helper script that converts the user edited wiki into mkdocs with the material theme like retroarch uses. Not sure if the devs would be interested in something like that or if they just want to keep a static repo, but its just an idea.


Sounds interesting. I’m of data input level so couldn’t do much to help with that unfortunately.

(Can’t comment on sheet from mobile and away from PC for a few days as sick)

As for the custom banners comment we could just drop some default text over the system image. 2010, 2003, accuracy etc

I can have a play with that as and when there is time.

For multi system banners maybe using the emulator logo would be OK, not sure on rights with that though. MAME logo for mame cores and bluemsx logo for that. Things like bluemsx and Genesis Plus/picodrive could also include smaller logos overlayed on the emu logo for all the systems it emulates. Again as and when there is time