4 ms·

Lakka is Retroarch packaged on top of a minimal Linux distro—like those distros that exist just to run Kodi, and, in fact, last I checked, it's build on exactly

Lakka is Retroarch packaged on top of a minimal Linux distro—like those distros that exist just to run Kodi, and, in fact, last I checked, it's build on exactly one of those (Libreelec, I think?). Retroarch is a frontend for libretro, which provides a set of APIs that emulators can use for I/O. If you can produce a library from an emulator that conforms to the APIs, then you've got what Retroarch calls a "core". Thus retroarch acts as a kind of target for emulators, that lets them all use a common frontend, including for things like button mapping (each emulator maps to a set of "fake" Retroarch inputs, which Retroarch then maps to your actual controller) or video output/filter settings. This is a different approach from other meta-emulators that typically invoke full, independent emulators as if running them from the command line, and try to manage them externally. And yes, there are multiple mame cores for Retroarch: https://github.com/search?q=libretro%20mame&type=Everything https://github.com/search?q=libretro%20mame&type=Everything [EDIT] Also, I've run Lakka on hardware as weak as a Raspberry Pi 2. You can't use fancy video filters (say, to make games look the way they did on a CRT TV or monitor) but it'll run a whole bunch of Mame games, plus all 8-bit console games and most from the 16-bit era at acceptable frame rates and latency. It also worked well enough to be comfortably playable for a surprising number of Playstation (PSX/PS1, the first one, that is) games and for exactly one of the N64 games I tried on it (Super Mario 64—all other N64 games were a lag-fest, if they ran at all, but that one was smooth and snappy). Any mini PC from the last 10 years is probably more powerful than an RPi2, so should do even better. RPi4 takes that "most" on the 16 bit era and makes it "all" and makes a bunch more N64 and Playstation games playable. Probably many Playstation 2 games as well, but I've not tried it.

matheusmoreira 5y ago
> including for things like button mapping (each emulator maps to a set of "fake" Retroarch inputs, which Retroarch then maps to your actual controller) Is this really necessary? Why not map input devices directly to core inputs? Makes configuration needlessly complex in my experience.
- rincebrain 5y ago
  Imagine that you swap out your GameCube + USB adapter controller for a PS5 controller. Now you only have one place to go remap buttons, rather than N. (That would be my guess, anyway.)
- brimble 5y ago
  That way the core authors don't need to know a thing about how the parent program (usually Retroarch, but it doesn't have to be) handles input re-mapping, and you can change all of them in one place—or use multiple for different cores, or even set it on a game-by-game basis, RA supports all that, too, and the cores don't have to care about it. It's less complex than a wrapper program having to know a bunch of different config formats and conventions. Again, cores run as shared libraries inside Retroarch. These "fake inputs" aren't, like, actual OS-level simulated devices. It's more like a core listens for events of type (name made up) "ra_analog_0" and treats anything coming in as left-stick x-axis positive-direction input, and by convention so do most or all other cores that emulate a system with a left analog stick (or perhaps with just one), unless they have a good reason not to, so default Retroarch-provided automatic input device mapping can make most common gamepads do something sensible with most cores, as soon as you connect them. Then if you prefer to swap left and right sticks, you do it one place and it works everywhere. Or if you prefer to swap left and right on just one game, you do that. The core never has to know about any of it.

matheusmoreira 5y ago

> including for things like button mapping (each emulator maps to a set of "fake" Retroarch inputs, which Retroarch then maps to your actual controller) Is this really necessary? Why not map input devices directly to core inputs? Makes configuration needlessly complex in my experience.

rincebrain 5y ago
Imagine that you swap out your GameCube + USB adapter controller for a PS5 controller. Now you only have one place to go remap buttons, rather than N. (That would be my guess, anyway.)
brimble 5y ago
That way the core authors don't need to know a thing about how the parent program (usually Retroarch, but it doesn't have to be) handles input re-mapping, and you can change all of them in one place—or use multiple for different cores, or even set it on a game-by-game basis, RA supports all that, too, and the cores don't have to care about it. It's less complex than a wrapper program having to know a bunch of different config formats and conventions. Again, cores run as shared libraries inside Retroarch. These "fake inputs" aren't, like, actual OS-level simulated devices. It's more like a core listens for events of type (name made up) "ra_analog_0" and treats anything coming in as left-stick x-axis positive-direction input, and by convention so do most or all other cores that emulate a system with a left analog stick (or perhaps with just one), unless they have a good reason not to, so default Retroarch-provided automatic input device mapping can make most common gamepads do something sensible with most cores, as soon as you connect them. Then if you prefer to swap left and right sticks, you do it one place and it works everywhere. Or if you prefer to swap left and right on just one game, you do that. The core never has to know about any of it.