If you are a developer who wishes to contribute to the development of RetroArch; or if you have found a bug and wish to submit a minor patch and/or bug report, please read this document.
Active discussions happen on our Discord, mostly within the Programming channel category. We value discussions that happen in real time around these contributions.
Please do note that contributors to RetroArch do such contributions within their spare time. We do prefer to keep a professional and non-aggressive atmosphere around the project, along with any disagreements to be settled professionally without insults, name calling, or otherwise. If there are any issues, we are willing to have discussions about it.
Bug reports in RetroArch may fall into one of two categories:
- RetroArch itself, the user interface and API around all of the various cores.
- Individual Core, of which interact with RetroArch.
When submitting a bug report, ensure that the report is submitted to the correct repository. For RetroArch itself, it is done by reporting a bug within the RetroArch repository. For other cores, please use the search function within the libretro Organization on GitHub. Issues that are specific to a core and not RetroArch are likely to be closed very quickly. If an issue is suspected with RetroArch, please make sure to test with multiple cores to be sure that is is not isolated.
If the issue occurs during runtime, please paste the verbose log output:
- If using the Pheonix interface, the log will be in File -> Show Log.
- If using the main interface, enable verbose logging with Settings -> Logging -> Logging Verbosity. Ensure both Log to File and Timestamp log Files is enabled.
- Otherwise, run RetroArch with the verbose (
-v) flag.
If the error happens during compilation and/or building, paste the output of ./configure
and make accordingly. If using an IDE, please paste any of the errors and log output.
Any and all contributions should be submitted through Pull Requests on GitHub. The process requires that you fork the repository, make the appropriate changes, and then open a pull request on GitHub. If your pull request is for a proof-of-concept then please indicate as such.
Your pull request will then be reviewed. There may be comments and requests for additional changes to be made. It may also be possible that the changes will not be accepted. Otherwise, it may be merged in when it is fully approved. The final approval of merge requests is at the discretion of the project.
If you want to develop a larger feature or make broad changes, please do join our Discord server to discuss. The discussion is necessary to prevent the possibility of major work being done which will not be accepted at all.
If you wish to contribute additional functionality to libretro's API, there are considerations that must be accepted. Please note that because this API affects multiple different projects, we highly value and require API and ABI stability and backwards-compatibility. Due to this requirement, there will be additional scrutiny in reviews for this added functionality.
Any and all features will be added only when necessary for an existing libretro core to properly function. Hypothetical implementations of libretro are not considered.
We highly value a consistent code style throughout the entire code base, please make sure you look through the existing code to get a feel for the coding style. When submitting a pull request, it may be asked to fix any coding style issues before submission. In other cases, there may be a follow-up pull request making the code style consistent.
For full guidelines please see the Coding Standards.
Some non-obvious things to be aware of:
- Code should be both C89 and ISO C++ compatible. This is a requirement for XBox 360 and MSVC to properly build. Think of it as a C++ compatible subset of C99.
- There must be no warnings in your code (enabled by
-Wallfor GCC compilers), do also note that different compilers may produce different warnings. - Avoid using deprecated APIs, these will be removed in the future at some point.
If you have contributed a chunk of source code that is written to you, you should add yourself to
the copyright header in the file. If you have made a significant contribution you should add
yourself to the AUTHORS file, adding your full name, e-mail, and the feature you worked on.
Contributors who show a good track record of pull requests over time may eventually get commit access to the repository. This may happen when looking through pull requests over long amounts of time becomes a burden.