Launch external games from RetroArch

[RobLoach]

RetroArch is a great frontend, but lacks the ability to run non-libretro-compatible games. Got an idea, and the result is Lutro Lutris Launcher. Was wondering if you guys thought this was crazy, or if there would be a better way around it. Would also love some help on improving it, if it's at all viable!

Also, Lutro is awesome, but could use a bit more love :wink: .

cc @strycore

[strycore]

Wow, this is neat! So now it'll really be possible to launch Steam from Lutris from RetroArch from Kodi :D Wonder how this will behave once we switch to libretro core based runners.

[inactive123]

This entire project all centres around the libretro API. This is an application ecosystem that honestly should have happened decades ago instead of mucking about with separate executables per program that all become outdated and die and decay over time and require continuous maintenance. Anything non-libretro falls outside the scope of this project and is not interesting to me. (but it goes deeper than not being interesting to a single individual like me, it is from a project perspective detrimental to the project).

I am not opposed to this launcher or anything, you can use it and all, I can see the point for you personally, I am not stopping you from doing it or whatever. So just to preface all that. As a project leader, though, and as a custodian of this project, it is not something that I am going to personally support though, and to be frank I honestly I think it is a big waste of time and having ports/programs that are not implemented through libretro and having RA launch those kills the entire concept of RetroArch, it kills the entire concept and point behind Lakka, it kills quality assurance, it really makes the entire thing fall apart. It is the reason why SteamOS sucks so badly in my opinion, you CANNOT have standalone games implemented through various means without going through some governing application API unless you want to have the entire gaming platform fall apart right in front of your nose, which is exactly what is happening on SteamOS with all of these terribad game ports.

I cannot disagree more with your assertion that 'RetroArch lacks the ability to run non-libretro programs'. It doesn't lack it, it's the entire point. Programs need to be reimplemented to use the libretro API, I will never, ever add 'launch external program' abilities to it because that is inherently the wrong way to do it. It's either going to be done properly (i.e. through libretro), or not at all.

I feel pretty strongly about this and I can't see myself ever changing my stance on this. And I find it personally to be terrible that Linux is getting a bad name right now amongst game devs because of this horrible half-baked effort called SteamOS and all of the crapware ports that are arriving on it. They couldn't have possibly executed it in a worse fashion, it couldn't have been a worse broken solution. Good concept, but absolutely terrible execution. At the very least I can find solace in the fact that every RA/libretro port is always, without exception, always better on Linux vs. Windows. This whole meme that 'Linux is bad for gaming' only holds true apparently when you don't care for it and resort to half-baked measures to churn out ports.

[inactive123]

Anyway, sure, if people find it useful, they can use it. We can even move it to the libretro organization so there's a better way for people to contribute it.

I don't want it interfering with the development and demand for libretro-based cores, though, since that is the entire project's goal. As long as that is understood then I'm fine with it, but I don't want us ever reaching a situation where RetroArch/Lakka is going to become some mish mash of standalone games/applications and libretro cores. That's where I will more or less draw the line.

[strycore]

I understand your concerns, and I'm not how that will work in the long run. We've planned switching as many binary runners as possible to libretro cores. I'm not sure how this will be implemented yet but if the current python bindings for libretro aren't production ready then I might just use retroarch to launch the cores. If this is the solution we choose, I'm not sure that using retroarch to launch lutris which itself launches retroarch would produce reliable results.

That said, if we can avoid using retroarch, that'd be even better but it might still generate conflicts.

[inactive123]

I have no idea what a 'runner' is or what your project is to be honest or what you're trying to accomplish.

[strycore]

Lutris is a gaming platform that supports every possible game that can run on Linux (native, Wine, emulation) https://github.com/lutris/ . We call runners every program capable of running games, this is the equivalent of cores in libretro. I maintain builds for a large number of emulators (https://github.com/lutris/buildbot/tree/master/runners) but, as you can imagine, everything would be much simpler and reliable if we used libretro, which is exactly what we're going to do.

[inactive123]

Lutris runtime is completely Python-based? This is why you were talking about these Python bindings for Libretro?

Honestly, in my experience, anything other than compiled languages is just going to suck from a performance perspective. I'd recommend just calling RetroArch directly then.

[strycore]

The client is written fully in python but its only goal is to install and launch games (what we call the lutris runtime is a set of libs we install alongside the client, similar to the steam runtime). If using python bindings is going to affect performance then yes, we'll probably use RetroArch. I haven't tested the 2 python bindings I found but if done correctly, they should just call the compiled libretro cores and have no effect on performance but maybe the bindings to a bit more than that. performance then yes, we'll probably use RetroArch. I haven't tested the 2 python bindings I found but if done correctly, they should just call the libretro cores and have no effect on performance but maybe the binding to a bit more than that.

[inactive123]

Which libretro frontend were you thinking of using then which is implemented in Python?

What do you mean calling the libretro cores? The libretro cores need a libretro frontend in order to run. So what are you going to use for that if not RA and if you are not going to write it yourself?

[strycore]

Lutris is the frontend, that why I was looking into python bindings. That said, I haven't studied how libretro works a lot so I'm not sure how much work goes between the game launcher and the cores. If this involves managing the display and handling input, then it is out of scope for the client and we'll rely on a fully native solution. From what I understand, this seems to be the case so RetroArch might be our best option.

[inactive123]

Well, from what I see, Lutris is just some launcher that calls external applications.

A libretro frontend requires (among other things) that you write audio/input/video code to deal with the libretro video frame, audio samples, and input that you get back from the core. I don't think any Python-based libretro frontend is at the level yet where it would compare favorably with RetroArch, and then there is libretro GL to consider (if any of them implement it yet).

At this point looking at the program itself, just go with RetroArch honestly and just call that as you would a WINE/Steam program or whatever, will save you time and your userbase will be happier for it too.

[strycore]

This is the best option indeed. We don't have any plans to implement code to handle audio/video/input (and if we did, it wouldn't be with python) and since there is RetroArch we have no reason to do so. My initial belief was that all I/O was handled by a general purpose library that RetroArch (or the python binding) would interact with, but this is not the case. Thanks for clarifying that!

[inactive123]

With RetroArch we basically wrote all code from scratch so that we didn't need to rely on SDL, GLFW or any other middleware. It's totally self-contained and all the better for it. It has had features like DRM/KMS and Wayland support long before SDL2 ever did, and it also has SDL2/1 frontend drivers in case you'd ever need it (but the non-SDL drivers in RA are more optimal anyway). So honestly, as far as Linux is concerned, a lot of work went into it to really cover nearly every conceivable input/audio/video API that Linux supports, so it will take a lot of work and time for any libretro frontend to really catch up with it.

[kivutar]

@RobLoach it can be a nice alternative for people that want to launch external apps from RetroArch. But I agree with @twinaphex that it ruins the advantages of libretro to launch programs this way.

If you go this way, why not just using love2d as frontend, and add a libretro plugin in love2d, so we would have a new libretro frontend based on love2d, able to run libretro games, with a great potential in term of menu design?

This way, you would contribute to the libretro ecosystem and to love2d at the same time, without defeating the purpose of the API, and with a real added value about UI prototyping.

[RobLoach]

Thank you all, @strycore @twinaphex and @Kivutar, for the feedback. I greatly appreciate all your thoughts on this, and the discussion is exactly what I was looking for when posting this issue. Some thoughts:

1. I agree that having everything ported directly through libretro is the real absolute solution. When I have the time, I'll build my own libretro core for something in the future to become more familiar with that process.
2. This Lutro Lutris Launcher is not something that should be delivered as part of the /libretro family of Lutro applications. It should live where it is. No question of that. @twinaphex, I apologize if my first opening statement came off as insulting what RetroArch does and accomplishes. I love everything about the libretro ecosystem.

3. @Kivutar What do you mean by the following? Something along the lives of what @leiradel was up to on https://github.com/leiradel/love-libretro ?

   why not just using love2d as frontend, and add a libretro plugin in love2d

[kivutar]

@RobLoach, no, I was talking about the exact opposite : adding libretro core support in love2d. So we could launch a SNES rom in a Löve game. This wouldn't be the first libretro frontend using Lua. But Löve is becoming portable (and ported) enough for this to be interesting.

[inactive123]

To be honest a libretro Love core is more promising.

[RobLoach]

@Kivutar adding libretro core support in love2d. So we could launch a SNES rom in a Löve game.

That would be interesting. I've seen other libretro frontends out there, but a love2d one does have some potential.

@twinaphex To be honest a libretro Love core is more promising.

That would be pretty nice. Considering love2d is on SDL, it shouldn't be that difficult to bring over. Do you have any documentation around porting project over to libretro?

[kivutar]

@RobLoach I don't remember about the documentation, but I know that there are some. I remember at least a PDF. But the best way is to real the "test" cores, that are here for educational purposes too. Those are stored in RA, iirc.

LÖVE have many backends, OpenGL, GLES, SDL. So we could start by a software rendered core with the SDL backend as you suggested. Every external dependancy have to be compiled statically and backed in the lib.

The challenge with LÖVE is that the runloop, which handles inputs, computing, and rendering, is implemented in a special Lua file. This allow users to override the love.run function, to completely change the behaviour. It can still be done with libretro.

LÖVE have something called liblove, that encapsulate all the functionnalities, and that we could use.

In fact, for our new handheld console project, we really need that core. It will be our first big step in the world of indie game devs. So if you have free time, let contact me on IRC and we can start doing a basic implementation together.

[RobLoach]

If you go this way, why not just using love2d as frontend

With the latest additions to Lutro, love-lutris can now run through either Love2D or Lutro with complete source parity. Thanks for the ideas! :+1:

There hasn't been any more work on the libretro port of liblove, correct?

[RobLoach]

https://github.com/robloach/love-lutris

[paperbenni]

Retroarch is a really great frontend, I love the ps4 aesthetic of xmb, but No game that was made today will EVER get ported to retroarch, we have to accept that! In my opinion you should just add a bash core. People will be happy and can't blame retroarch if something doesn't work.

[RobLoach]

Made ChaiLove-Launcher which runs scripts/programs at will. Just add the bash commands you want to chailove-launcher.json, and then you'll be able to run them.

[paperbenni]

Thanks, I know about these community made, but native support would still be nice and wouldn't break all the time.

[Ferk]

Imho, portability is a huge part of what makes the libretro ecosystem so great.

A general launcher of this type would not be able to run content reliably and reproducibility across different environments, let alone architectures.

No game that was made today will EVER get ported to retroarch, we have to accept that!

What about Dinothawr? It was made explicitly around libretro.

Of course I don't expect AAA publishers porting their games, or any game that uses too many dependencies making it not portable.

But things like Love2D and PICO-8 have communities of people making new little games for them that I don't see why it couldn't happen for Retroarch, taking advantage of its features. I'd really like it if something like lutro or chailove took off.

[paperbenni]

Dinothawr is basically a tech demo without focus on the actual game. And talking of a consistent user experience and ecosystem, having to ssh into my lakka box every time I want to do anything that the retroarch interface doesn't allow because of apparent toxicity towards python and literally anything else is absolutely ridiculous. Just making a Linux core that can scan for and run normal Linux executables would require next to zero effort and wouldn't make anything else worse.

[RobLoach]

Just making a Linux core that can scan for and run normal Linux executables would require next to zero effort and wouldn't make anything else worse.

Would love to see something like that. Feel free to use libretro-dolphin-launcher as a base.

[hizzlekizzle]

@RobLoach Seems someone on the forum did just that to make a bash launcher core: https://github.com/SwedishGojira/libretro-bash-launcher

I don't know enough C/++ to do it, but I figured preceding the 'command' line with a function to get the filename and invoke it with system() would make a multiplatform script/executable-launcher.

[paperbenni]

That one doesn't work for some reason and I don't know why.

[heuripedes]

I suggest locking this issue up.

The only viable "launcher" core I can think of is a mplayer/mpv/ffmpeg launcher that uses X11 embedding[1], piped audio and stdin commands so the frontend can properly take over and control input/output like it is supposed to. I can't think of any emulator or game that does this and this sort of thing is probably not even available in non-X11 systems. Additionally, some systems don't have proper window management so if for any reason the launched program doesn't have an exit button the user is basically locked and will have to reboot the machine or switch to a tty.

Whoever wants to launch things from Retroarch is better off inserting a random menu item that calls fork() && exec() to launch some third party application and not give a damn about whether it is running properly or setting the user's home on fire. I cannot help but think making a core for such things is just plain busywork.

[1]: RetroArch does not support embedding nor does it support being embedded elsewhere. Something similar could be achieved with off-screen rendering or perhaps piped video output.

[paperbenni]

I wouldn't use this to play games, I'd use it to sync savestates with a cloud storage or anything like that. And anything that can launch stuff would be sufficient for that, I don't need it to communicate with libretro.

[yhojann-cl]

To run a steam game without paths use steam steam://rungameid/373180 by example. Is a great idea launch the external games from retroarch, for example, to main application for arcade machines and steam apps like as Neon drive, Kung fury, Mortal kombat XL, etc.

[maxiducoli]

How i can run lutro games in RetroArch windows from commandline?

I use: retroarch.exe -L "/cores/lutro_libretro.dll" "\RetroLife\roms\lutro\tetris.lutro"

Then flash a window, close and just create a folder with tetris name in RetroLife\roms\lutro\ but does not launche the emulator.

Some solution please?

[RobLoach]

That's correct... What do you find in the logs? Any error that occurs?

See more at https://docs.libretro.com/guides/cli-intro/

[maxiducoli]

Fixed!! Error with --log-life "xxx" -v

Error on audio I change the driver and now works!

[Shituation]

This entire project all centres around the libretro API. This is an application ecosystem that honestly should have happened decades ago instead of mucking about with separate executables per program that all become outdated and die and decay over time and require continuous maintenance. Anything non-libretro falls outside the scope of this project and is not interesting to me. (but it goes deeper than not being interesting to a single individual like me, it is from a project perspective detrimental to the project).

I am not opposed to this launcher or anything, you can use it and all, I can see the point for you personally, I am not stopping you from doing it or whatever. So just to preface all that. As a project leader, though, and as a custodian of this project, it is not something that I am going to personally support though, and to be frank I honestly I think it is a big waste of time and having ports/programs that are not implemented through libretro and having RA launch those kills the entire concept of RetroArch, it kills the entire concept and point behind Lakka, it kills quality assurance, it really makes the entire thing fall apart. It is the reason why SteamOS sucks so badly in my opinion, you CANNOT have standalone games implemented through various means without going through some governing application API unless you want to have the entire gaming platform fall apart right in front of your nose, which is exactly what is happening on SteamOS with all of these terribad game ports.

I cannot disagree more with your assertion that 'RetroArch lacks the ability to run non-libretro programs'. It doesn't lack it, it's the entire point. Programs need to be reimplemented to use the libretro API, I will never, ever add 'launch external program' abilities to it because that is inherently the wrong way to do it. It's either going to be done properly (i.e. through libretro), or not at all.

I feel pretty strongly about this and I can't see myself ever changing my stance on this. And I find it personally to be terrible that Linux is getting a bad name right now amongst game devs because of this horrible half-baked effort called SteamOS and all of the crapware ports that are arriving on it. They couldn't have possibly executed it in a worse fashion, it couldn't have been a worse broken solution. Good concept, but absolutely terrible execution. At the very least I can find solace in the fact that every RA/libretro port is always, without exception, always better on Linux vs. Windows. This whole meme that 'Linux is bad for gaming' only holds true apparently when you don't care for it and resort to half-baked measures to churn out ports.

Wellp... 2022 here and RetroArch is now ringing bell and wistles on STEAM closed source, needs to run under their API and it sucks your private data. I love how these "activists" end up biting the dollar, it is also the reason nobody makes gaming in linux as good as in windows, they close the doors. Face it, linux will never be for gaming with this set of mind. Hell, even the OS's are too complicated for normal users, most stuff has to be done using the terminal and then you have the paranoia of linuxers, the permissions drama, even copy/pasting files is a mess that has to be done from the terminal because most programs do things with root privileges and save files under root restricted folders, if you have to move those files, edit, whatever, you HAVE to make it using the terminal which most people are afraid/don't understand or like me got fed up of losing time instead of just dragging an dropping the files like in windows (which has also a comprehensive file system and don't have a soup of folders with symbolic links taking you into a rabbit hole back to the start).

RetroArch is really cool but it lacks the ability to launch external programs. Yes. Its a lack not a feature.

PS: I can hear you from here screaming "fanboy!". No. Windows 11 for instance is a disgrace. I only use what is more convenient. Linuxers = Vegans from the computer world.

PS 2: Linuxers in the sense of "activists" or "fanboys" not normal people using that OS (which is fine)