0 users browsing Discussion. | 1 guest  
Main » Discussion » Retroarch's (controller) interface is an bad abstraction
Pages: 1 2 3 4 Next Last
Posted on 19-02-21, 06:23 (revision 1)
Post: #16 of 76
Since: 10-31-18

Last post: 19 days
Last view: 18 hours
(in reply to https://helmet.kafuka.org/bboard/thread.php?pid=1524#1524 )

I have some theories about Retroarch's interface (mostly N64):

- Main menu is designed for game controller use, not keyboard/mouse.
- I wish I could search the entire options hierarchy, like Jetbrains IDE setttings.
- Different config options available from the menu, vs. in-game.
- I don't understand the difference between global, per-console, per-game config.

One config interface for every console under the sun:
- You have to manually map your controller to retroarch's Retropad abstraction (ABXY, L1L2L3, etc...) then read the docs to find how the RetroPad abstraction is mapped to the per-console buttons.
- I feel that a "global controller abstraction" causes problems with consoles with controllers that don't fit the mold.
- Some N64 games use C buttons individually. IIRC, Retroarch only lets you bind L/R and U/D to controller axes. Retroarch Mupen64Plus has no option to bind C buttons separately. Retroarch ParaLLel has an option, but it's confusingly organized because...

Autogenerated GUI based on per-core metadata?
- It's like the worst of a text editor dump (no ctrl+F) and the worst of a GUI (no organization) and a non-native console-style interface (tedious and slow to use: scroll 1 line at a time, can't click to jump to line).
- I'm not entirely sure how to edit N64 video plugin settings.
- If I recall, m64py also uses autogenerated graphics plugin GUIs based on config files. The config files have comments. The GUI doesn't. m64py is also hard to configure in ways.

-----------

Eventually I got OOT running mostly fine in Retroarch on Ubuntu 18.04... except the audio would be interspersed with bursts of noise, and fiddling with audio buffer length/etc. would randomly change/fix the issue... And my display would keep turning off during gameplay (which is OK until the display turns off and Retroarch freezes). At that point I decided to play VC on my Wii instead.
Posted on 19-02-21, 10:40

Post: #88 of 210
Since: 10-29-18

Last post: 240 days
Last view: 212 days
Can't remember if I ever got any Sega CD ISO to work with it. If I did, it took a while. Even hunterk was stumped.
Posted on 19-02-21, 12:28 (revision 1)
Post: #17 of 76
Since: 10-31-18

Last post: 19 days
Last view: 18 hours
lemme just post a follow-up:

I think retroarch's controller abstraction tries to do too much (too many consoles). I recall byuu talking about how Higan's UI is clunky because it has to handle too many consoles, but I haven't noticed any issues from that (yet).

I think Higan's options screens are at least intuitively laid out (unlike Retroarch, which has the extra task of presenting per-plugin options to the user). Though I ran into the issue where "higan isn't responding to controller input settings say I have Gamepad selected and all bindings correct, but the Super Famicom menu (which is hidden until you open a game) says I have None controllers connected".
Posted on 19-02-21, 17:27 (revision 1)
Post: #13 of 60
Since: 10-29-18

Last post: 6 days
Last view: 5 hours
There's basically 2 ways to do input: you map once to an abstraction and cores tie into that abstraction by some (changeable) default, or you map nothing by default and a person needs to come in and map each thing separately/manually.

RetroArch (and MAME EDIT: and Steam) went with option 1, IIRC higan goes with option 2.

The more cores you have (>100 with RetroArch, thousands with MAME), the heavier the burden of option 2. The weirder the input scheme of the core, the heavier the burden of option 1.

People like to rag on the N64 mapping for libretro, but it's based on the VC classic controller mapping, so I'm not sure how switching to your Wii VC helped you there. I was never a fan of the R2 as C-button shift concept, but after using it for a few minutes, I started to like it a lot. You can, however, try the WIP updated mupen64plus-libretro-nx core, which approaches C-button mapping in yet another way: https://github.com/libretro/mupen64plus-libretro-nx
Posted on 19-02-21, 22:19
Burned-out Genius Developer
Post: #13 of 48
Since: 10-30-18

Last post: 275 days
Last view: 42 days
> The more cores you have (>100 with RetroArch, thousands with MAME), the heavier the burden of option 2. The weirder the input scheme of the core, the heavier the burden of option 1.

A key point to consider is, how many of the emulated systems are people actually using? higan currently has 22 unique hardware devices supported. Of them, I imagine 90% of people only use the SNES core. The other 10% probably use no more than three or four systems. I doubt a single person is playing ColecoVision + SNES + Benesse Pocket Challenge V2 games in higan.

My focus is on allowing absolutely anything to be emulated with higan. I'm intending to have things like solar sensors, barcode scanners (eg Barcode Battler), card scanners (eg eReader), toy scanners (eg Soul Dollz), save devices (eg Super Turbo File), etc supported. Trying to map all of this to a universal controller is never going to work.
Posted on 19-02-22, 08:03 (revision 3)
Post: #117 of 361
Since: 10-30-18

Last post: 1 day
Last view: 22 hours
If you want Mupen64+, just use Bizhawk and avoid the awful Front-End's for Mupen64+ as well as the clunky and very unintuitive RetroArch UI. RetroArch does not save anything to the HDD if you click the X in the toolbar (including save game data). That alone is plenty of reason to not use it.

Bizhawk will save to the HDD if you click the X. The only minor downsides to Bizhawk (compared to RetroArch) are:

1) The first 4 button bindings for the N64 controller are poorly labeled (they are for 100% analog stick movement in a direction regardless of how much you move the stick, analog stick sensitivity and axis calibration is handled in another tab within the controller binding UI)

2) the graphics plugin UI for GlideN64 is custom, missing a loooot of info that the official graphics plugin provides (no tooltips) and also uses different names for options than what the official plugin uses so you can't easily reference existing GlideN64 documentation to figure out what an option does nor easily figure out which options are the most accurate.

3) Shader Cache and custom texture packs are hardcoded to use the following illogical location: %UserProfile%\AppData\Roaming\Mupen64Plus\ (this may change in the future). Annoying since the Shader Cache can become corrupted resulting in whacky graphics, requiring you to delete the cache to fix it. Also unintuitive to have Bizhawk users store their custom texture packs in a Mupen64Plus folder.

AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64
Posted on 19-02-22, 09:16
Post: #18 of 76
Since: 10-31-18

Last post: 19 days
Last view: 18 hours
I would use Bizhawk, but last time I tried (years ago on Windows, don't remember graphics plugin), performance dropped precipitously on resolutions above 640/800x600, while m64py/retroarch didn't break a sweat. (Somebody told me this is normal due to "improved accuracy" in bizhawk, but I'm skeptical.)
Posted on 19-02-23, 08:03 (revision 4)
Post: #120 of 361
Since: 10-30-18

Last post: 1 day
Last view: 22 hours
Bizhawk uses an Interpreter (very accurate), not a Recompiler (less accurate but much faster). This alone has a significant impact on emulation performance. Try setting PJ64 or RetroArch to use the Interpreter and see how performance goes for a better performance comparison.

On my 9 year old CPU I too can't go above 640x480 internal rendering resolution without performance issues in Bizhawk (640x480 is plenty fine though).

AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64
Posted on 19-02-23, 20:42 (revision 2)

Post: #31 of 88
Since: 11-04-18

Last post: 245 days
Last view: 245 days
Posted by Nicholas Steel
If you want Mupen64+, just use Bizhawk and avoid the awful Front-End's for Mupen64+ as well as the clunky and very unintuitive RetroArch UI. RetroArch does not save anything to the HDD if you click the X in the toolbar (including save game data). That alone is plenty of reason to not use it.

Bizhawk will save to the HDD if you click the X.


ah yes,the idiot's button.You can simply exit RetroArch using esc you know...

RetroArch has three levels of configuration I believe; the RetroArch global configuration file, a core configuration and a game configuration file. I believe the core cfg will override the global one and the game cfg, if you have one, will override the core options. The configuration files will only save what's different I think, so the core config will save anything different from the global config and the game config will save anything different from the core cfg

better explained here: https://docs.libretro.com/guides/overrides/
Posted on 19-02-24, 03:19 (revision 2)
Post: #121 of 361
Since: 10-30-18

Last post: 1 day
Last view: 22 hours
Posted by DonJon
Posted by Nicholas Steel
If you want Mupen64+, just use Bizhawk and avoid the awful Front-End's for Mupen64+ as well as the clunky and very unintuitive RetroArch UI. RetroArch does not save anything to the HDD if you click the X in the toolbar (including save game data). That alone is plenty of reason to not use it.

Bizhawk will save to the HDD if you click the X.

ah yes,the idiot's button.You can simply exit RetroArch using esc you know...

How is a widely used basic O/S feature dating back to at least WIndows 3.0, an idiot's button?

AMD Ryzen 3700X | MSI Gamer Geforce 1070Ti 8GB | 16GB 3600MHz DDR4 RAM | ASUS Crosshair VIII Hero (WiFi) Motherboard | Windows 10 x64
Posted on 19-02-24, 03:42 (revision 1)

Post: #91 of 210
Since: 10-29-18

Last post: 240 days
Last view: 212 days
New in bsnes:
- option to auto-save states when unloading a game or closing the emulator
- option to auto-load aforementioned states when loading games

Also yeah, wtf? the idiot button? What is your preferred method?
File -> Quit?
Alt+F4?
Right-click-> Close?
Condescend on a bulle...oh wait...
Posted on 19-02-24, 03:45
Custom title here

Post: #269 of 876
Since: 10-30-18

Last post: 1 day
Last view: 1 hour
The only true way to close a program is C-x C-c

--- In UTF-16, where available. ---
Posted on 19-02-24, 05:04 (revision 1)

Post: #33 of 88
Since: 11-04-18

Last post: 245 days
Last view: 245 days
> Condescend on a bulle...oh wait...

hmm didn't you told NS to calm down just a few posts ago? not everything is a personal attack you know? And I wasn't replying to you so a bit strange reacting like that...wait...

I was referring to when you accidentally close an application when trying to minimize or resize an app hence why many or most programs have the "Are you sure you want to quit" exit confirmation now, in order to avoid any stupid mistakes in other words

Hope that clears any misunderstandings
Posted on 19-02-24, 06:10 (revision 1)

Post: #92 of 210
Since: 10-29-18

Last post: 240 days
Last view: 212 days
I did told NS you know? You don't reply to my post on a bulletin board thread? OK, maybe some misunderstandings...
Posted on 19-02-24, 07:08 (revision 1)
Post: #22 of 76
Since: 10-31-18

Last post: 19 days
Last view: 18 hours
I don't like how Retroarch closes the program when you press Esc I think only dialogs (and logically speaking, Retroarch's overlay menu) menus should close, not the entire program (without confirmation? I don't remember).

Dolphin asks for confirmation before closing, when you press Esc.

edit: I think i unbound that shortcut pretty soon after downloading retroarch.
Posted on 19-02-24, 08:30

Post: #52 of 119
Since: 10-29-18

Last post: 151 days
Last view: 13 days
Posted by jimbo1qaz
I don't like how Retroarch closes the program when you press Esc I think only dialogs (and logically speaking, Retroarch's overlay menu) menus should close, not the entire program (without confirmation? I don't remember).

Dolphin asks for confirmation before closing, when you press Esc.

Yeah, I have run into a similar situations before, resulting in much frustration. Even just pausing the emu with a confirmation dialog would suffice.

I still have no idea what I'm talking about.
Posted on 19-02-24, 19:54

Post: #39 of 88
Since: 11-04-18

Last post: 245 days
Last view: 245 days
Posted by KoiMaxx
Posted by jimbo1qaz
I don't like how Retroarch closes the program when you press Esc I think only dialogs (and logically speaking, Retroarch's overlay menu) menus should close, not the entire program (without confirmation? I don't remember).

Dolphin asks for confirmation before closing, when you press Esc.

Yeah, I have run into a similar situations before, resulting in much frustration. Even just pausing the emu with a confirmation dialog would suffice.


Correct. if you want to pause the emulation without quitting it's F1, at least by default I think. esc will quit without asking for confirmation

one thing that bothers me is how you apparently cannot completely unbound the guide button for xb360 controllers like you can do so for other keys for some reason, only replace it with something else. So by default for the 360 the guide button brings up RetroArch's menu, same as F1.

well actually there is a way to get around that: you have to manually edit the cfg file and map the guide button to something like gamepad button 90.Basically something higher than the number of keys on the gamepad so that when you press it since it's mapped to something that's not there obviously nothing happens
Posted on 19-03-01, 14:39

Post: #10 of 14
Since: 11-15-18

Last post: 320 days
Last view: 19 days
Are there ways to use Retroarch cores aside from Retroarch? I pretty much only use it for the PSX emulation since it seems to have the most accurate sound emulation I've been able to find. Not a fan of the GUI, it's a pain to use.
Posted on 19-03-01, 16:36
Post: #14 of 60
Since: 10-29-18

Last post: 6 days
Last view: 5 hours
There are other libretro frontends, though not all of them support all of the spec (and therefore not all cores will work, though a majority should work).

Some notable examples are GNOME Games, BizHawk, Kodi, Alcaro's minir, RetriX (for Win10 and Xbone, IIRC), the bonkers desktop/multimedia environment Arcan, and EmuVR (though it's really a VR environment that runs RetroArch on in-game TVs), among many others that are not really intended for casual gameplay.

Also potentially of interest is the in-rapid-development Ludo (from kivutar, who also is the main guy behind the Lakka minimal RetroArch-based Linux distro), which is focused on being simpler and more accessible than RetroArch, and another minimal CLI-focused frontend from tehcloud (who is also the maintainer of Nestopia UE), though this one isn't released yet.

RetroArch also has a more normal-ish Qt WIMP UI that you can bring up by hitting F5. You can't currently change settings through it, but that's coming very soon (as in, there's a guy working on it as we speak), and you can already use it to launch games and create/edit/manage playlists.
Posted on 19-03-01, 23:56
Not from my cellphone

Post: #181 of 716
Since: 10-30-18

Last post: 15 hours
Last view: 5 hours
Oh, that's nice to know.

I don't mind having a classical window+menubar UI for traditional desktop usage. And after having tested PicoDrive's standalone UI, I actually liked it for controller usage: it's very simple, clean, doesn't get on the way, I get a list of filenames rather than a library view (which as I've said elsewhere gets annoying if you have several dozens or even hundreds of games, particularly ROM hacks), and generally, it does the work for me.

But still, the problem with those multi-console emulators is rather simple: too many eggs on the same basket. What I would do if I were a emudev would be group consoles by family, as those usually have similar controller mappings: for example, all Sega consoles share the same basic layout introduced with the SMS, they just kept adding buttons: the Genesis/MD initially added an extra button plus START, then XYZ+Mode; the Saturn was more of the same - even the 3D Pad just added a stick or two. Then they got fancy with the Dreamcast, but aside of the VMU, it was nothing but the Saturn 3D pad, which was a Saturn controller with sticks, which was a Genesis controller with extra buttons, which was a oversized SMS pad with a bunch of extra buttons. For Nintendo consoles, the history is more or less the same.

Model the controller abstraction around families, not "all gamepads are Xbox 360 controllers".

Licensed Pirate® since 2006, 100% Buttcoin™-free
Pages: 1 2 3 4 Next Last
Main » Discussion » Retroarch's (controller) interface is an bad abstraction
[Your ad here? Why not!]