0 users browsing Discussion. | 9 bots  
    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 77
    Since: 10-31-18

    Last post: 951 days
    Last view: 878 days
    (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: 1638 days
    Last view: 1610 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 77
    Since: 10-31-18

    Last post: 951 days
    Last view: 878 days
    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: 1404 days
    Last view: 1326 days
    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 51
    Since: 10-30-18

    Last post: 1181 days
    Last view: 1104 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 426
    Since: 10-30-18

    Last post: 261 days
    Last view: 1 day
    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 77
    Since: 10-31-18

    Last post: 951 days
    Last view: 878 days
    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 426
    Since: 10-30-18

    Last post: 261 days
    Last view: 1 day
    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: 1644 days
    Last view: 1644 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 426
    Since: 10-30-18

    Last post: 261 days
    Last view: 1 day
    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: 1638 days
    Last view: 1610 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 1150
    Since: 10-30-18

    Last post: 6 days
    Last view: 1 day
    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: 1644 days
    Last view: 1644 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: 1638 days
    Last view: 1610 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 77
    Since: 10-31-18

    Last post: 951 days
    Last view: 878 days
    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 158
    Since: 10-29-18

    Last post: 628 days
    Last view: 7 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: 1644 days
    Last view: 1644 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: 1719 days
    Last view: 946 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: 1404 days
    Last view: 1326 days
    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
    Dinosaur

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

    Last post: 4 days
    Last view: 22 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, enemy of All Things JavaScript™
    Pages: 1 2 3 4 Next Last
      Main » Discussion » Retroarch's (controller) interface is an bad abstraction
      This does not actually go there and I regret nothing.