Reicast-emulator: Downstream projects & 3rd party / unofficial forks

Created on 18 Jul 2018 · 11Comments · Source: reicast/reicast-emulator

Unofficial packages

arch linux has one
pandora package by @ptitSeb (is this even "unofficial" at this point?)

Direct downstream projects (projects that use reicast as is)

Closed source downstream projects (closed source projects that use reicast)

Products that bundle reicast (eg, I think GPD used to package some version built it?)

Forks with significant code changes

libretro
?

Uncategorized

RetroArch http://www.retroarch.com/
RetroPie https://github.com/retropie/retropie-setup/wiki/Dreamcast
EmuStation
There's another comercial one somone told me about on FB and I forgot it's name :(

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Documentation

Source

skmp

Most helpful comment

One of the main reasons I am collaborating here is because I hope in doing so, we can finally get rid of stigmas like 'unofficial forks/ports' when it comes to the libretro core. I hope that we will see much more adoption and support for our project in our collaboration here.

twinaphex on 19 Jul 2018

👍3 ❤1 🎉1

All 11 comments

the retropie fork is here: https://github.com/RetroPie/reicast-emulator

maybe the retropie differences could be incorporated upstream, and then the retropie script could be updated to just build the upstream version: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/reicast.sh#L24

@gizmo98 might have an opinion here!

dankcushions on 18 Jul 2018

@dankcushions
Our fork is outdated. All relevant changes (dispmanx and omx support) were posted and merged upstream. Upstream is running fine on a pi. I had no time to test retropie controller configuration with upstream. Keyboard works fine. If there is no problem retropie script can be updated.

gizmo98 on 18 Jul 2018

👍2

twinaphex on 19 Jul 2018

👍3 ❤1 🎉1

@gizmo98 would be great if you can test that. @twinaphex are the libretro build changes in mainline at all?

skmp on 21 Jul 2018

No, it will take many changes to do that. We're looking at a longer-term project there. I am fine with getting it upstream, but it's best to get there by baby-steps, one thing at a time. Give me some time to rebase the codebase on my end first to allow this to be an easier transition.

twinaphex on 21 Jul 2018

👍2

Also https://github.com/batocera-linux/batocera.linux/tree/master/package/batocera/emulators/reicast might be of interest

skmp on 23 Jul 2018

@skmp checked. Controller works!

gizmo98 on 26 Jul 2018

@gizmo98 so the scripts can be updated to use upstream directly now?

skmp on 27 Jul 2018

@skmp I have tested an older raspbian jessie installation. When omx and dispmanx support was merged i tested with a raspbian stretch test installation. I will do a final raspbian stretch test with an up to date installation. After that i will do a PR.

gizmo98 on 29 Jul 2018

🎉2

@gizmo98 thanks :)

skmp on 30 Jul 2018

reicast has a CLA, which typically requires the commit author's signature. This means that any commit returned upstream from a fork of reicast also requires a CLA signature.

This leaves two options for handling the commit. Either attempt to get the original author to put in the extra work of modifying and resubmitting it to reicast or alter the commit's recognized author by resubmitting it with a reference to the original commit (similar to how libretro handles reicast).

Inconveniencing authors and destroying history are unfavorable last resorts to working around a CLA, so is there any benefit to the CLA that outweighs promoting poor use of git?