Very nice, but there probably shouldn't be a setting for this and it should be the default behavior. I hate it when there are tons of unintelligible knobs on an application if everything could be computed automatically.
Given the number of platforms that RetroArch runs defaulting any new behaviour to off makes sense. Particularly for features like this which are global.
I've spent hours and hours trying to get controls working correctly in RetroArch. There are independent controls for the menu, cores then individual roms.
There have been so many times where I've accidentally locked myself out of the menu controls causing the need to SSH into the device to fix it up.
Maybe I haven't found the right settings, but I would say that RetroArch is significantly worse than MAME. MAME will show you the relevant inputs for the running machine, whatever they are: sticks, trackballs, button, pedals, you name it. RetroArch will show a generic configuration menu without taking into account each machine's peculiarities.
For example, I have a Megadrive-like 6-button controller and I'm trying to configure a Megadrive core... no luck, you can only configure an SNES-like controller with A, B, X, Y, L and R. Where are C and Z? Apparently you need to hand-edit some text files, and pray to the Machine God that it will work.
Was shocked too. It probably should really have just a reasonable "defaults" + "ADVANCED" menu with all that tuning... Anyway for me default fine in all the games I've tried.
Agreed, but I can also see why they would hesitate a bit with RetroArch being used in all sorts of scenarios, some that come to mind:
- Powerful computers (so should be on by default)
- Embedded devices (ON or OFF depending how well it works and how much more CPU it uses)
- Portable emulation devices (totally should be off to save battery life)
It's hard to come up with a sensible default here, especially when a lot of people might upgrade, see the game runs worse/uses more battery and downgrade right away before inspecting changes.
My assumption was that frame delay exploits the fact that CPU are way faster than original hardware (hence you can defer computation later since it will take less anyway) and since the most common trick to increase battery life is to slow down the CPU, eating away at your extra budget, you would want frame delay disabled, but that is definitely not correct.
If anything, Automatic Frame Delay would probably help letting you tune in CPU speeds without worrying too much about adjusting the Frame Delay as well.
Interesting that this is even possible. I would've thought each core would have to implement it independently and many would not ever be compatible with it.
I don't know how RetroArch is architected in regards to interacting with the cores, but if it does so by calling a `run_frame()` function or something similar, then all it has to do is delay calls to that function. I imagine it is a bit more complicated than that though.
It's so ironic that RetroArch is going through so much trouble to squeeze latency out of video (even running the emulator midway through a frame), yet the Arch Linux package disables the JACK audio backend (the only non-exclusive audio backend that doesn't buffer extra audio on top of the ALSA buffers, alongside ALSA which is buffer-free when talking directly to speakers, and PipeWire which RetroArch doesn't support), and I can't enable JACK in the Flatpak even though it's not explicitly disabled, and RetroArch comes out of the box with a whopping 64 ms of audio latency.
18 comments
[ 2.9 ms ] story [ 41.8 ms ] threadThere have been so many times where I've accidentally locked myself out of the menu controls causing the need to SSH into the device to fix it up.
For example, I have a Megadrive-like 6-button controller and I'm trying to configure a Megadrive core... no luck, you can only configure an SNES-like controller with A, B, X, Y, L and R. Where are C and Z? Apparently you need to hand-edit some text files, and pray to the Machine God that it will work.
Even worse is initial setup can't bootstrap without M+KB.
- Powerful computers (so should be on by default)
- Embedded devices (ON or OFF depending how well it works and how much more CPU it uses)
- Portable emulation devices (totally should be off to save battery life)
It's hard to come up with a sensible default here, especially when a lot of people might upgrade, see the game runs worse/uses more battery and downgrade right away before inspecting changes.
My assumption was that frame delay exploits the fact that CPU are way faster than original hardware (hence you can defer computation later since it will take less anyway) and since the most common trick to increase battery life is to slow down the CPU, eating away at your extra budget, you would want frame delay disabled, but that is definitely not correct.
If anything, Automatic Frame Delay would probably help letting you tune in CPU speeds without worrying too much about adjusting the Frame Delay as well.
Fore-warning, for your sake, dont use RetroArch!! It's a huge huge tweakfest, page after page of tweaking.
RetroArch, i think rightfully, targets power users.