RetroPie integration

[rhaleblian]

Split out previous comments mixed into #52 , the FR for libretro support.

[rhaleblian]

There appear to still be "optional" and "experimental" packages in RetroPie that don't utilize libretro. Nonetheless I suspect that the RetroPie maintainers would prefer a libretro core. Looks like nothing in the "core" package list is non-libretro.

I was splicing my own fork of linapple into the RetroPie scheme as a personal thing, based on what understood from that exercise I say it'd be possible here. A "from-source install" (my term) defined in RetroPie is generally (1) installing dep os packages, (2) pulling a Git repo, (3) building, (4) installing into the RetroPie filetree.

I got interested in a libretro port of linapple, but a port of gsplus would be cooler.

I might give it a stab if time permits, but somebody should ask the RetroPie maintainers how they like to accept new emulators.

[rhaleblian]

Oh, the other important bit is to devise a CLI means to pass a disk image to GSplus in RetroPie's ecosystem. You need to be able to express a shell command that does that.

[rhaleblian]

[rhaleblian]

While a step towards RetroPie inclusion, the above doesn't speak to the original request -- libretro support, which means becoming a libretro core. In emulationstation, the joystick is pretty messed for me. That'd be the primary benefit from libretro i think.

Looking at the very screen above implies that hatari hasn't become a libretro core. Bummer.

[rhaleblian]

Also, the choice of what slot to boot from has a bearing on slot 6 working for non-GS games.
This can be controlled by modifying the config file bram entries. I tried doing this JIT and it was working -- i could boot 5.5" disk from slot 6 or a 3.5" from slot 5.

[rhaleblian]

Work on this is being pushed to
https://github.com/yoyodyne-research/RetroPie-Setup/tree/gsplus
https://github.com/yoyodyne-research/gsplus/tree/retropie

[knghtbrd]

There appear to still be "optional" and "experimental" packages in RetroPie that don't utilize libretro. Nonetheless I suspect that the RetroPie maintainers would prefer a libretro core. Looks like nothing in the "core" package list is non-libretro.

I don't think we're going to see GSplus a "core" part of RetroPie anytime soon just because the audience for Apple II games is a lot smaller than most of the "optional" packages.

Still, I'd like to see GSplus support RetroPie well. Few things other than RetroArch-based emulator cores really tend to "feel right" on RetroPie, so it seems like the path of least resistance. I don't think it's the best solution technically, however, because trying to implement a general purpose computer emulator as a libretro core always winds up putting you at odds with libretro's intended purpose: To provide video, sound, controller input, and ROM file handling to a console emulator. Basically, do do all the hardware stuff for you!

There are a number of things that GSplus could do without libretro to make it play better with RetroPie. First, it could read the controller setup provided by RetroPie as configured through EmulationStation. Note an edge case here: In the event RetroPie's controller is a keyboard and the only defined controller, GSplus should start up assuming no joystick. It should also support exiting out of the emulator using a defined controller sequence (select+start or menu+start are typical).

The ability to define multiple floppies (for games that have them) in a game-specific config file and define a "next disk" controller action would also be really cool for that. Basically most RetroPie players are going to want to use their gamepads for as much as possible, and they're going to have a lot more than the usual Apple two-button stick, so … yeah, that should be doable.

Linux keybindings are kind of a problem too. Can't three-finger-salute GSport on Linux with ctrl-alt-F12 because that changes virtual terminal out from under you. I think ctrl-alt-escape still brings up task manager on Windows, but it had some binding under Linux too. Plus RetroPie users might not have a typical 104 keyboard, so some configurability might be necessary.

Most else is pretty minor, probably. Just stuff that hasn't been the highest priority.

Most of the stuff that's directly supported by RetroPie's scripts was contributed by someone who made it work. There's usually not much expectation that general-purpose computer emulators integrate all that well into RetroPie's usual RetroArch scheme because of the above reasons … but there's no reason why GSplus can't integrate better than most, even if I think trying to conform to libretro.h sounds like a recipe for frustration.

Probably best I not comment about the non-technical part, since anything I'd say there would FAR overshadow the technical question in a major way. I have reasons to not want to work on it anymore, but I was also present for an event and aftermath of it that still turns my stomach to this day. So … not a positive view of the project. The API … it's all right for what it does. I'd do it differently, but maybe not so differently at the time it was sketched out.

[rhaleblian]

You make good points here.
I haven't touched this in ages and probably won't, honestly. It was good to look under the libretro hood a bit.
I would say put the libretro bit aside and look at easier things for RetroPie integrations.

Recently I took the IIGS emulation in MAME standalone for a spin and it'll run some games. If the libretro flavour could have the same mileage...

Y'all feel free to close this or whatever. -r

[knghtbrd]

I'd keep the ticket around for the kinds of things I suggested above that might help make it a little more usable in the RetroPie environment. It's Dagen's project, though, I just use it. 😁 Even LinApple's not really mine, whatever GitHub has to say about it. If I have time to dig into either, I might see if I can contribute something toward the above described front-end friendliness.