Jump to content
LaunchBox Community Forums

Emulator Cores - An open letter to the developers


robwired

Recommended Posts

@ckp

I do get the point and what you are saying is just wrong.

You are comparing an emulator / frontend combo that is tied directly to each other which is OpenEmu to a front end only which is Launchbox.

You may not want to buy the hardware excuse but it is a legitimate part of the whole equation. Macs are very locked down in their hardware and OS compared to a Windows PC.

What is being asked in this thread is for Jason to basically just replicate all the work that the Retroarch team and the OpenEmu team have done over several years but by himself. At the same time both Retroarch and OpenEmu are very locked down in what systems they emulate using open source emulators which makes programming a directly tied in front end to handle all the controller and audio functionality much easier but extremely limiting.

@Thatman84

We are reading these posts correctly. OpenEmu and Retroarch are very specific UIs built for very specific emulator cores which are open source and allows them to do it but it takes time.

And once again I will say this for the last time.

All of what is being said is technically possible given enough time or enough money for Jason to hire a dev team. I and others including Jason have already stated as much. But it would a massive undertaking considering licensing issues because of the commercial nature of Launchbox and then you have to figure out which emulators you are going to tie in and which ones you won't because you can be sure that once some got tied in someone will be on here complaining that emulator x isn't tied in.

Link to comment
Share on other sites

4 minutes ago, d3cyph3r said:

OpenEmu is a fancy front end for Retroarch but uses a couple cores that are not RA ones. Bliss comes to mind for Intellivision.

Actually it's not. I thought OpenEmu used the libretro cores as well but someone over on the Retroarch forums said they weren't. I am assuming they are just doing what Retroarch does which is take open source emulator code and build a UI and other back end functionality on top of it.

Link to comment
Share on other sites

OpenEmu is an emulator. Retroarch is an emulator. Multi-faceted? Yes. Have their own UIs (not run from command-line)? Yes. Do those UIs aim to serve the same basic function of organizing games (albeit atrociously in the case of RA)? Yes. Does that make them in any way comparable to Launchbox? No. They support what they support and that's it. You can't take ePSXe and drag it onto Retroarch and now you've got an ePSXe core. They're self-contained collections of emulator modules, not a true frontend.

Launchbox is not, has never been, and was never designed to be an emulator. Again, in and of itself, it doesn't emulate anything. It's a frontend. It allows you to plug whatever emulators you want into it, even multi-faceted ones like Retroarch; but it doesn't hook into them to the same degree as what's being suggested because it's not working within that kind of limited architecture (because it's not an actual emulator).

If you have a garage, and a car in that garage, and a CD in that car's stereo, are you going to complain that the car lets you hit the skip button to change tracks but the garage doesn't? I hope not, because why would you? The garage is there to store the car (or a fleet of cars if it's big enough), which happens to have a stereo. It's not there to control the stereo. That's not to say that you can't sit in the garage, get in the car, and start up the stereo, just that it doesn't make much sense to bemoan the garage's feature set for something it was never designed to do.

Link to comment
Share on other sites

My personal point was there are things that can be done to make configuration easier and more enjoyable to get to gaming faster. Whether it takes years or weeks really isn't my point. Just suggestions coming from a user. Take it over leave it.

  • Like 1
Link to comment
Share on other sites

Sorry guys if my complete lack of programming knowledge is shining through. I'm here to learn and thank you for your efforts 

If you wouldn't mind just confirming we are on the same page for my suggestions.

Is it easy or hard for LaunchBox programming wise to automate the setup of things like RetroArch control inputs, turning on overlays, shaders and downloading the cores? Maybe this is best left to RocketLauncher or the standalone emulators.

That is all I'm suggesting. Not coming packaged with built in ports of emulators just automating some of the emulator setup to give a more global feel to the experience and removing some of the need for a user to understand every program aswell as a frontend on top.

Link to comment
Share on other sites

2 minutes ago, Thatman84 said:

Is it easy or hard for LaunchBox programming wise to automate the setup of things like RetroArch control inputs, turning on overlays, shaders and downloading the cores?

That's something that really only Jason could answer, but it would entail a level of interaction between frontend and emulator that simply doesn't exist currently in LB. Even RocketLauncher only kinda does some of this stuff, and it's a convoluted mess as far as I'm concerned. Some people love it, and more power to them, but I'm not one of them.

Retroarch itself already automates control inputs, though you can of course tweak as you see fit.

Turning on overlays/shaders isn't something that's automated by Launchbox, but there are ways to setup multiple "profiles" via separate emulator entries in Launchbox so that you can switch between them from one game to the next relatively simply. I've done that pretty extensively in my setup. We can get into that if we need to, but that probably warrants a separate thread if so.

Core selection itself can be somewhat subjective. Again this goes back to there not always being a one-size-fits-all solution in some (or even many) cases, so this isn't something I'd even necessarily want to be automated. However, it's not unreasonable to think that some generalizations could/should be provided that would at least make this selection process easier, and that's basically what the auto-populated platform command line-parameters (from a fresh RA emulator entry in LB) are designed to do. How up to date those are at this point, I'm not entirely sure as I've changed so many things since I first added in Retroarch, there's no telling how much of it is original (suggested by LB) and how much of it is custom. I know that's a point that Jason is certainly well aware of though. There are ways to somewhat automate the process of keeping them up to date though, if you so choose - things like Stellar. I still do it the old fashioned way myself though.
 

32 minutes ago, Thatman84 said:

That is all I'm suggesting [...] just automating some of the emulator setup to give a more global feel to the experience and removing some of the need for a user to understand every program aswell as a frontend on top.

And again, I think that's perfectly reasonable in theory. I've certainly spent hours of my life yelling at my computer because something just isn't doing what it should. I wish that wasn't the case; and I certainly don't wish that on anyone else either. Being able to just press a button and have everything work would be great. It's just when you consider how many separate brains, how many lines of code, how many disparate pieces of hardware and software, and just as disparate developer personalities are involved across the huge spectrum of emulation, that's often easier said than done. :/

  • Like 1
Link to comment
Share on other sites

Short answer is no, it's not easy to automate the setup of things like Retroarch control inputs through Launchbox.

Longer answer is Retroarch already does this for you anyways right out of the box, there is no reason for another program like Launchbox to even do this for you.

It's funny that RocketLauncher gets brought into this subject of making things easier for the end user when RocketLauncher is absolute atrocity when it comes to doing that. RL makes everything way more complex than it needs to be.

Controller setup and settings always going to be best left to the emulator and not the front end unless somewhere down the road Jason decides to implement open source emulator cores / code directly into Launchbox.

I think there is a bit on confusion here for some people think about Retroarch and OpenEmu. I think people think they are emulators and while if you think this you aren't entirely wrong but you are wrong none the less. Retroarch and OpenEmu are merely user interfaces built for the specific task of controlling the emulator code used on the back end. In the case of Retroarch it is using the libretro cores which are developed by their own devs.

Let's take an emulator like Higan (formerly known as BSnes) as an example here. You can go out and you can download Higan and it has it's own UI to control it and set it all up. Or you can go out and download a previous version (when it was known as BSnes) which has since been released as open source. You can then take the code and build your own UI on top of it and you make modifications to that code to improve or make worse in some cases. This is what Retroarch and OpenEmu do, they work based of older BSnes code (typically 0.94) and they build on it. They make changes in the emulation itself which is the real nitty gritty work and then they throw their own UI on top of it.

For Launchbox to do this Jason would need to do exactly what Retroarch and OpenEmu does and that is take the code that exists openly and then develop a UI for it and tie it directly into Launchbox. This is where the extra work that I and Zombeaver are trying to explain comes into play. It is not something trivial to a one man operation that Jason is, Retroarch and OpenEmu have a dev team that has worked years to do this, go back and look at Retroarch's UI pre version 1.2 and you will see how awful its UI used to be compared to nowadays. Keep in mind this option is only available to emulators that are open sourced and each and every single emulator "core" would have to have it's own functions tied into the UI. Now do you see why this job is so big ? Keeping in mind that this is not an option for closed source emulators such as ePSXe or SSF.

The only other way to achieve the sort of controller setup automation being asked for here is to use something like the module system that RocketLauncher has and that again makes things even more complicated than they already are. When a new emulator comes out you have to wait for module to be written for it or if an emulator changes the module has to be changed to support the new changes. Just go talk to the people who use RocketLauncher already who are coming here because Launchbox is so much simpler.

Of course you can always just use RocketLauncher already and link that into Launchbox but again you are now getting back to the more complicated way of doing things which is what is being asked.

And around the fucking merry go round we go.

Edit:
Again, not saying it's not possible to do, just a case of time and money. Either Jason gets the money to pay a dev team to do it or he puts in a stupid amount of time to do it himself while putting every single other wishlist feature that people want on the back burner for a very extended amount of time

Link to comment
Share on other sites

31 minutes ago, CliveBarker said:

WE0DRqN.gif

I have done that so many times since I joined a few forums. I hope you are entertained. :) 

EDIT Quoted wrong person (while updating I read your reply lordmonkus, still think you are missing the point mate) Retroarch works on text files for settings. LaunchBox could have the ability to edit those text based files from within LaunchBox without opening RetroArch UI. I think easily but maybe not)

19 minutes ago, lordmonkus said:

 

 

 

*Deleted reference to wrong post

 

Edited by Thatman84
quoted wrong post
Link to comment
Share on other sites

29 minutes ago, Zombeaver said:

That's something that really only Jason could answer, but it would entail a level of interaction between frontend and emulator that simply doesn't exist currently in LB. Even RocketLauncher only kinda does some of this stuff, and it's a convoluted mess as far as I'm concerned. Some people love it, and more power to them, but I'm not one of them.

Retroarch itself already automates control inputs, though you can of course tweak as you see fit.

Turning on overlays/shaders isn't something that's automated by Launchbox, but there are ways to setup multiple "profiles" via separate emulator entries in Launchbox so that you can switch between them from one game to the next relatively simply. I've done that pretty extensively in my setup. We can get into that if we need to, but that probably warrants a separate thread if so.

Core selection itself can be somewhat subjective. Again this goes back to there not always being a one-size-fits-all solution in some (or even many) cases, so this isn't something I'd even necessarily want to be automated. However, it's not unreasonable to think that some generalizations could/should be provided that would at least make this selection process easier, and that's basically what the auto-populated platform command line-parameters (from a fresh RA emulator entry in LB) are designed to do. How up to date those are at this point, I'm not entirely sure as I've changed so many things since I first added in Retroarch, there's no telling how much of it is original (suggested by LB) and how much of it is custom. I know that's a point that Jason is certainly well aware of though. There are ways to somewhat automate the process of keeping them up to date though, if you so choose - things like Stellar. I still do it the old fashioned way myself though.
 

And again, I think that's perfectly reasonable in theory. I've certainly spent hours of my life yelling at my computer because something just isn't doing what it should. I wish that wasn't the case; and I certainly don't wish that on anyone else either. Being able to just press a button and have everything work would be great. It's just when you consider how many separate brains, how many lines of code, how many disparate pieces of hardware and software, and just as disparate developer personalities are involved across the huge spectrum of emulation, that's often easier said than done. :/

Thanks for this was a lot more helpful for me to understand.

 

It seems as always, what some want will be different to what others want and really what we all want is almost been done already! But "we" always want more!! 

Edited by Thatman84
added comma
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...