Introducing the Bounty System

One of our goals with getting on Patreon was to experiment with using a bounty system to encourage contributions from outside of the normal libretro/RetroArch/Lakka team, and we’re finally ready to take a stab at it. This is uncharted territory for us, so some of this framework is bound to change as we move forward, but here’s our initial plan:

  1.  The libretro team makes all final decisions on bounty allocations and disbursements. While we intend to listen closely to community input, ultimately we have to be able to make the final decisions.
  2. All contributions must follow coding guidelines and meet approval of the libretro team before disbursements will be awarded. We can’t pay out if the code isn’t usable and/or maintainable by us.
  3. Pursuant to #2, potential contributors should contact the libretro team prior to beginning work to make sure the final product will be acceptable. This is intended to avoid misunderstandings and other conflicts. We don’t want someone to work hard on a fix or feature only to find that it’s not going to be acceptable for whatever reason.
  4. We will try to do as much as we can through Bountysource, where we can link specific issues from our Github repos to bounty values. This is especially applicable to smaller tasks. However, it may not be appropriate for all tasks, and we’ll decide how to deal with those that don’t exactly fit on a task-by-task basis.
  5. Pursuant to #4, potential contributors should contact the libretro team and determine an actual disbursement value based on the magnitude and difficulty of the task. We may need to negotiate up or down to find a fair value, based on the contributors’ skillset, or the amount of tutoring needed to get contributors up to speed with the codebases/APIs involved, etc.
  6. Disbursements can be made in the form of cash payments, the purchase of hardware for development and/or testing, etc. We want to be able to help developers with whatever they need. Sometimes that will be in direct payments, other times it may be in specialized hardware for porting/maintaining or reverse-engineering or whatever.
Again, this framework is a work-in-progress, so if you have any questions or concerns, feel free to contact us, either on Github or in #retroarch on Freenode IRC.

Happy New Year!

We at Libretro wish you all a happy New Year! 2016 has been quite the year for Libretro as a project, so let’s briefly recap where we stand at the end of this year and what we managed to do in 2016 –

First with Vulkan

We were one of the first programs to ride the Vulkan wave, and we managed to add Vulkan support to RetroArch since Day One of the new graphics API’s release.

Continue reading “Happy New Year!”

RetroArch 1.3.4 released

Version 1.3.4 has just been released.

Builds can be found here.

Old MacOS X builds (PowerPC and 32bit Intel) will be retroactively added soon, since these builds can’t be automated.

Graphics improvements

 

This is the simplified ribbon animation shown here. The more advanced one should be fullspeed on any GPU from 2008 and later.

Continue reading “RetroArch 1.3.4 released”

RetroArch 1.3 released

RetroArch 1.3 was just released for iOS, OSX, Windows, Linux, Android, Wii, Gamecube, PS3, PSP, PlayStation Vita and 3DS.

You can get them from this page:

http://buildbot.libretro.com/stable/1.3.0/

Once again the changelist is huge but we will run down some of the more important things we should mention:

Continue reading “RetroArch 1.3 released”