|Re: [hatari-devel] Any interest in accepting RetroArch libretro core patches?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 08/20/2016 09:29 PM, David Savinkoff wrote:
----- Jamie Bainbridge wrote:
You may be aware of an emulator project called RetroArch at
RetroArch is an framework which takes existing emulators, librarises
them into "cores", and executes the core through an existing generic
display/sound/input frontend. The result for end users is that they
configure the frontend once and all their emulators just work. It's
Hatari has been a libretro core since 1.8.0 with a shallow fork at
https://github.com/libretro/hatari created by one of the main
You can see the 20-or-so patches required to add RetroArch support.
They are mostly self-contained in the libretro/ directory, though
there are a few display/sound/input changes through the code which are
separated with "#ifdef __LIBRETRO__". These patches appear to apply
cleanly over the Hatari 1.9.0 source.
I am writing to ask if you would like to add these libretro patches
directly into Hatari?
If you could provide a source code
diff -ur hatari-1.9.0 hatari-1.9.0-libretro > hatari-1.9.0-libretro.diff
that applies as a patch with
patch -p0 < hatari-1.9.0-libretro.diff
that compiles from source into a working executable.
This would provide the most concise information for all.
Better to mail the patches as separate attachments to the list,
to discuss which of the patches would be OK to be folded into
This would allow your source tree to just automatically be built as a
RetroArch core. The default is to build as Hatari currently does,
__LIBRETRO__ must be explicitly defined during build for the
preprocessor to create the RetroArch core, so hopefully you consider
this a non-invasive change to accept.
I ask this because I would like to update RetroArch's Hatari to v1.9.0
and to future versions as well, but this requires converting hg to
git, then either rewriting upstream git history with a rebase of
1.8-to-1.9 and rebase of libretro changes and force push, or a lot of
manual tedious merge conflict work to apply 1.9 directly over the
It would make a RetroArch Hatari core a lot easier if your upstream
repo supported it already.