RetroArch - Thoughts About Potential Guide/Article

[racketboy]

So as I was working on writing about Emulation on the SNES, I've been researching RetroArch. I haven't really dug into it much prior as I haven't done much PC/console/handheld-based emulation lately (And I have OpenEmu on my Mac).

I was thinking it would be cool to do an introductory guide/article like I did with MiSTer last year
http://www.racketboy.com/retro/mister-f ... eservation

Now I might not go into as much high-level stuff as most people are probably more familiar with software emulation, but I think there's still potential to pitch the benefits in an interesting way without intimidating beginners.

So here's some questions for you...

For those that are RetroArch veterans:
* What do you wish you knew about RetroArch sooner?
* What features do you end up using the most?
* What features that have been rumored / announced are you most looking forward to?
* What unannounced features would you like to realistically see in the next 5 years?

For those that are less experienced:
* Are there sub-topics you're interested in learning more about?
* What things about emulation are more intimidating to you?

Any other feedback/suggestions you have for a piece like this, please let me know.

BTW, can you tell I have more time on my hands during quarantine?


EDIT: Full article/guide published here http://www.racketboy.com/retro/retroarc ... mizability

[samsonlonghair]

Speaking for myself, I need to know two things: the why and the how. What are the advantages of retro arch over single-system emulators? How do I get my games up and running?

I’m more familiar with older emulators like SNES9x or GENS that just emulate one system (or a group of similar/related systems like KEGA Fusion). I’ve certainly heard of retro arch, but I fail to see the advantage of emulating dozens of different, unrelated systems in one application. Is there some hidden advantage that makes retro arch so popular? I’m sure there must be something to it that I don’t see.

It’s been a while since I looked at Retro arch. I seem to recall that the user interface struck me as... austere. So I would find it helpful to read a simple walkthrough of how to go from a fresh installation, to loading cores, to mapping controllers, to booting ROMs. Every time I try to dive into it, I find myself saying, “this would be so much simpler if I used such-n-such emulator,” or, “why the heck do I need to fool around with cores anyway?”

I guess I’m getting old. I remember when I was explaining to other people how to use emulators. Now I’m the one scratching my head.

[marurun]

I think the basic interface is confusing, but it's worth a look because of all the cores. Basically, RetroArch is sort of a glorified front-end and the emulation is done by different cores.

[samsonlonghair]

I think the basic interface is confusing, but it's worth a look because of all the cores. Basically, RetroArch is sort of a glorified front-end and the emulation is done by different cores.

So... not to be argumentative, but... if it’s a glorified front end, then shouldn’t it have a better GUI? Why is a glorified front end with a bad GUI so glorified?

I’m not trashing it; I just don’t see what makes it so popular. There’s got to be something to it aside from GUI. Much more colorful frontends like Maximus and Hyperspin have been around for a long time. OpenEmu is a multisystem emulator with a really slick front end called WIMP that I like a lot.

But something makes RetroArch the most popular. Maybe there’s something about RetroArch that developers find attractive. Maybe the devs just find it easier to plug their cores into RetroArch than... say... LaunchBox.

Maybe it’s the libretro API that developers like so much?

[marurun]

Honestly, I don’t emulate much at all anymore, so RetroArch is a little outside my experience. I did try to
get it installed on my laptop but the interface put me off. People keep using it and touting it so there must be something to it.

[Anapan]

I find even the new (Ozone) UI is cumbersome. Particularly, redefining controls is just painful. I understand it's because it's cross-platform and everything has to be able to be run from basic controls, but because of that, and the linux based device assignment, choosing which device will control what, and assigning different-from-default controls to different devices is a chore. Add to that per-core settings, and settings saving. It makes trying to explain a basic thing like reassigning default analog controls from digital to an analog joystick for player two like trying to verbally describe how to solve a maze.

[nightrnr]

Not sure that I have much insight as I may fall in the "less experienced" camp.

I find Retroarch useful only if you already plan to put a bunch of emulators on one device. Choosing your core can be beneficial for compatibility sake, but a concise key for pros/cons of each core would be useful. I will use it eventually maybe. I think I even ran into a full key/legend to each core once in a random forum.

For older systems (PC, PS2, PSP, and Xbox) I'll use the old stuff, even if retroarch has been offered for them. Retroarch for PS2 was a disaster for me (but then it is pretty low end for this).

Personally, I really only would use retroarch for Wii U and for PS Classic (and only because it seems to be the only real options for those systems). But it does seem a bit convoluted in practice. Dedicated emulators just have a better feel and ease of use to them, even if it's not a Swiss army all-in-one utility program.

And that's the thing: when I emulate, I tend to use what is easy or simple or dedicated in purpose. If things lose their focus, they tend to not get used.

Not sure if any of that was helpful.
I actually DO want more info for the 2 systems I intend with it.

Oddly, Retroarch could also be most helpful for when you DON'T put a lot of roms on there. You just have an "everything" emulator for when you want to try games at random and need it to play without searching for other programs to make them work.

Finally I think retropie is maybe the biggest reason for this. A raspberry pi for emulation really isn't designed for individual emulators. Still haven't set mine up for that purpose yet (and maybe never will).

[hobbes_182]

I have been using RetroArch for about two years now, casually of course. And I must say that a how-to guide will be extremely beneficial for the retro community.

Personally, I did experience a HUGE learning curve in order to get my favorite systems up and running. As mentioned before, the UI is very confusing. Plus the variety in cores per system can be daunting for anyone looking to get into RetroArch for the first time.

A guide featuring some best cores to get users started, which systems need BIOS and a detailed how-to on connecting and hosting online games would be fantastic (that last one still has me scratching my head).

I spent countless hours on their forums looking for answers only to end up with more questions.

Not to mention their own video tutorials seem to be out of date as well.

[racketboy]

I think the basic interface is confusing, but it's worth a look because of all the cores. Basically, RetroArch is sort of a glorified front-end and the emulation is done by different cores.

So... not to be argumentative, but... if it’s a glorified front end, then shouldn’t it have a better GUI? Why is a glorified front end with a bad GUI so glorified?

I’m not trashing it; I just don’t see what makes it so popular. There’s got to be something to it aside from GUI. Much more colorful frontends like Maximus and Hyperspin have been around for a long time. OpenEmu is a multisystem emulator with a really slick front end called WIMP that I like a lot.

But something makes RetroArch the most popular. Maybe there’s something about RetroArch that developers find attractive. Maybe the devs just find it easier to plug their cores into RetroArch than... say... LaunchBox.

Maybe it’s the libretro API that developers like so much?

I think you have very valid points and I may just quote you in my write-up.
But I think it probably gets most acclaim on non-traditional PC environments like Raspberry Pi, Android devices, and such.
But on top of that, I think most of the appeal is in the API and some of the things that get standardized -- then adding some other other newer features on top.

On the Mac, I use OpenEmu while accomplishes most of what it would do on a PC but looks nicer.

I find even the new (Ozone) UI is cumbersome. Particularly, redefining controls is just painful. I understand it's because it's cross-platform and everything has to be able to be run from basic controls, but because of that, and the linux based device assignment, choosing which device will control what, and assigning different-from-default controls to different devices is a chore. Add to that per-core settings, and settings saving. It makes trying to explain a basic thing like reassigning default analog controls from digital to an analog joystick for player two like trying to verbally describe how to solve a maze.

So would you say RetroArch ends up creating just as many problems than it solves when it comes to controller mapping and such?

Choosing your core can be beneficial for compatibility sake, but a concise key for pros/cons of each core would be useful. I will use it eventually maybe. I think I even ran into a full key/legend to each core once in a random forum..

I have been using RetroArch for about two years now, casually of course. And I must say that a how-to guide will be extremely beneficial for the retro community....
A guide featuring some best cores to get users started, which systems need BIOS and a detailed how-to on connecting and hosting online games would be fantastic (that last one still has me scratching my head).

I probably won't cover more in-depth things in this guide, but I could see that as a part 2. I would need a lot more time and experience with that. But I like the idea.

[Anapan]

So would you say RetroArch ends up creating just as many problems than it solves when it comes to controller mapping and such?

As a standalone emulator, it's difficult to manage.
In Windows, I only use it for a couple of the cores from a different front-end. As a command-line launched emulator with manually text-edited configuration files for only a couple of cores, it's not any worse than launching most other emulators from command-line while invoking external configuration files.
On Raspberry-PI, it's a similar situation for most cores. The EmulationStation frontend and per-core configuration files are used here as well. There are other front-ends for these systems, but I've not tried them.
The worst is trying to deal with Bluetooth controllers on Android via it's touch-screen controls.