Porting Emulators to Libretro

RetroArch General
#1

Hey all, just trying to get a better understanding of how all these emulators work together from a coding standpoint, and had a few questions.

When porting an emulator to libretro, would that emulator automatically be supported on all platforms that libretro is implemented on? Or are there other dependencies that certain emulators require outside of libretro (like DX, OpenGL, SDL, 3d rendering capabilities in software/hardware, etc)?

When a said emulator is updated by it’s original author, is it difficult to move the changes downstream into the libretro implementation? How hard is it to keep everything up-to-date?

Does the libretro/retroarch team commit changes to any of the emulators it uses?

If I understand correctly, the upcoming MAME 2010 and 2013 cores have replaced MAME’s SDL code completely by using the libretro API (is that right?). Does the removal of SDL improve the speed/efficiency of MAME? How well does this API work?

Thanks ahead of time for the answers. Really impressive stuff what you guys have done here with this API and getting so many systems and cores supported! Amazing! Huge respect btw, for your posted mission.

#2

Your first question, yes, any core ported to libretro is automatically supported on all the platforms libretro supports. If an emulator targets libretroGL the device would require 3D rendering capabilities. I guess a core by itself won’t have any other dependencies.

The second one, as far as I understand it depends on authors of the original emulators if they accept changes upstream. I guess if a port is not accepted upstream and there are radical changes to the emulator porting again would be a hassle.

#3

Libretro porting is generally a case of mapping/wrapping the emulator/game/whatever’s internal API to the corresponding libretro functions and/or callbacks. So, many ports are very shallow and require little-to-no modification of the existing core code. A number of these, like Snes9x and Genesis Plus GX, have been accepted upstream in the form of a self-contained ‘libretro’ directory that just sits unobtrusively in the top-level source directory. Other cores may require more extensive modification–frequently to excise things like SDL–and these changes are usually not accepted upstream.

Yes, it’s quite common for cores to work better via libretro than using their native GUIs (particularly with respect to latency). RetroArch’s drivers are very simple and native to the individual platforms, unlike SDL, which works in a lot of places but isn’t particularly great on any of them.

#4

Wow, great info to know. Thanks for the responses guys!