51922ea5be
2934af8af0 Added Patreon sponsor link. c8f18b6f0f Getting current program only when required for vglDrawObjects. 4c5d136b0d Added directive to enable vitaShaRK usage from cmd. 4a10df3be5 Minor adjustments and bugfixes. 14a0124acf Added GL_TEXTURE_LOD_BIAS support. 40c8c6205e Added GL_NONE def and fixed glUniform4f impl. 868079c51e Added glUniform4f implementation. 0a682cbad2 Typo fix. be3ce61ae7 Added GL_DEPTH_BITS and GL_STENCIL_BITS support. 21e6d1d330 Added runtime shader compiler support. 696e40bc62 Beautify error handler code. 537b37b110 Added glUniform3fv implementation. 7dd1403015 Fixed GLenum size and added missing types defines. 0c75f27ff1 Moved to NEON optimized memcpy usage. 98951895de Added gluPerspective implementation. 23e0b0b309 Fix for vglInitExtended not working on sys app mode. 4989c33ef5 Run clang-format. 429f1c1d8a Added system mode support. 9231680d02 Initializing sceGxm before free mem checking on vglInitExtended. 091e5e7882 Added vglInitWithCustomSizes. f4c646ea78 Added vglSetParamBufferSize. 1b9a063c41 Beautify some code. 089e81efc5 Fix for duplicated symbols 789dcbf812 Typo fix in readRGBA4444. 1514a4b2cb Disabling lto due to it being broken on vitasdk with gcc 9.1. fca18d9ab7 Added support for RGBA4444 texture format. d449f12808 Added support for RGB565 texture format. git-subtree-dir: deps/vitaGL git-subtree-split: 2934af8af083a9acf598ab75233c518a251c6f0d
3.3 KiB
Contributing to RetroArch
If you are a developer and want to contribute to the development of RetroArch, please read this. If you have found a bug and want to submit a minor patch or a bug report, please read this as well.
Submitting a bug report
When submitting a bug report, make sure that the bug is local to RetroArch. A bug in a libretro core or something deemed to be external is likely to be closed very fast. If you still suspect a bug in RetroArch, make sure to test with several cores to make sure.
If you have troubles building RetroArch on Linux/BSD/OSX, make sure to paste shell output of ./configure, as well as config.log and shell output of make. If building on Windows, just paste shell output of make.
If the issue occurs during runtime, make sure to paste RetroArch's verbose log. If using Phoenix frontend, you can find log in (File -> Show Log) after running. In console, make sure to run with verbose (-v) flag.
Pull Requests
Outside contributions are generally only accepted in the form of a pull request. The process is very simple. Fork RetroArch, make your changes, and issue a pull request on GitHub. This can all be done within the browser. The changes are reviewed, and might be merged in. If the pull request isn't acceptable at the time, note that it's possible to continue pushing up commits to your branch.
If you want to develop a larger feature, we'd like to discuss this first (ideally on IRC) so that you don't risk developing something that won't be merged. A pull request with a proof-of-concept is fine, but please indicate so.
libretro API
If you wish to add functionality to libretro's API, it can take some time to merge in, because changes to libretro API will affect other projects as well, and we highly value API/ABI stability. Features will only be added when deemed necessary for a concrete libretro core to function properly. Features will not be added on basis of hypothetical libretro implementations.
Coding style
Having a consistent code style throughout the code base is highly valued. Please look through the code to get a feel for the coding style. A pull request may be asked to fix the coding style before submission. In other cases, a pull request may be followed up with a "style nit commit".
Non-obvious things:
- Code should be both C89 and ISO C++ compatible. This dual requirement is for XBox360 and MSVC in general. Think of it as a C++ compatible subset of C99.
- Warnings are not allowed (-Wall). Make sure your code is warning-free. Note that warning sensitivity differs a bit across compiler versions.
- Using deprecated APIs is discouraged.
Copyright Headers and AUTHORS
If you have contributed to a part of a source file (a chunk of code that's written by you), you should add yourself to the copyright header in that file. If you have contributed significantly (a feature, a contribution you can "name", e.g. "Added audio driver foo"), you should add yourself to AUTHORS file. We'd like your full name and email, and which features you have been part of.
IRC
Active development happens on IRC. (#retroarch @ irc.freenode.org) We value discussing things in "real-time".
Commit Access
Contributors who show a track record of making good pull requests over time will eventually get commit access to the repo. This typically happens when the "overhead" of looking through pull requests over time becomes a burden.