RetroArch: Automatic Frame Delay to reduce input latency | Hacker News Reader

RetroArch: Automatic Frame Delay to reduce input latency

libretro.com

73 pointsrixrax18 comments

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.

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.

How does this use more battery power? Seems like it just does the same work at a different time.

That's my bad, you are correct!

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.

Doesn't it? Smaller delay means more fps, and thus more processing power.

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.

RetroArch is very nice but I do agree with has sadly fallen into MAME input configuration territory. All it needs is better defaults.

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.

I think the move to Ozone as the default UI was a big step forward in this regard.

Boy howdy do I know this pain.

Even worse is initial setup can't bootstrap without M+KB.

> I hate it when there are tons of unintelligible knobs on an application

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.

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.

Even worse when you have an application with no knobs, and "automatic computation" — essentially a heuristic as in this case — gets its wrong.

Given the number of platforms that RetroArch runs defaulting any new behaviour to off makes sense. Particularly for features like this which are global.

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.

all the more reason to compile it oneself. it was the only way i could get ffmpeg encoding to work properly.

Reply on news.ycombinator.com