Frame delay VS run-ahead

So, which is more efficient and less/more taxing on the CPU? Is Vulkan or GL a factor as well?

They have nothing to do with each other, so not sure what kind of comparison you’re looking for :stuck_out_tongue:

GL vs Vulkan doesn’t matter, other than the one that gives you higher FPS will allow higher frame delay and has less chance of bottlenecking run-ahead.

As far as i understand, regardless of how they actually work, both are meant to reduce input lag, right? So they are both meant to do the exact same thing. Let’s say i want to cut 1 frame of lag; which of the two will do it with less CPU power?

No, they do different things. Run-ahead removes internal game lag caused by the game itself. Frame delay removes external lag caused by the delay between the emulator rendering a frame and the GPU displaying it.

Frame delay does not increase CPU load. It simply delays the emulator a bit so that it reads player input later.

Run-ahead does increase CPU load, because it needs to rewind the emulation and also run the emulator twice (if “use second instance” is enabled.)

Oh, thanks for the explanation :slight_smile:

However, it seems that, at least at first glance, frame delay does eat quite a bit of CPU, as setting it to more than 6 ms (half a frame), produces stuttering in audio and video. On the other hand, run-ahead set to 1 frame (which i imagine eliminates 1 frame of lag) still allows me to play the exact same game full speed (fbneo core).

The stutter is not due to more CPU load. It’s due to the emulator not being fast enough to render the frame in the remaining time. For a 60FPS core, you have 1000/60 (16.7) milliseconds of time to render one frame. If the emulator can render it in 10ms, then you can use a frame delay of 6ms. If the emulator can render each frame in 5ms, then you can use 11ms delay.

If you set the frame delay too high, then the emulator runs out of time to render the frame. That’s what causes the stutter. So the faster your system is, the higher a delay you can use, but doing so does not increase CPU load.

Sorry for being such a knucklehead, but i always thought that a faster CPU equals better performance in emulation (especially 2d one). Are these lag oriented settings comunicating differently with the system CPU compared to the rest of the variables inside the emulator?

Edit: so, reading a bit more carefuly your reply, i think i understand. It’s about how a certain core/game is handled in Retroarch. So regardless of the hardware, that game in that core version will not be able to have a higher frame delay. Am i getting it right?

No. The faster your hardware is, the higher you can set the frame delay, because on faster systems, the emulator can emulate each frame in less time.

Let’s say the emulator can emulate 1 frame in 10ms. There’s still 6.7ms left until the next screen refresh (which happens every 16.7ms.) So the emulator emulates 1 frame, then RA waits 6.7ms doing nothing before it can show that frame. However, with frame delay, RA tells the emulator to start emulating the frame later. So instead of emulating the frame and then waiting 6.7ms, with frame delay you can first wait 6ms, then start emulating the frame, and by the time that’s done, RA can show the frame on the screen immediately.

2 Likes

So, if I understand correctly, the whole point of frame delay is to reduce the interval of time between the rendering of the frame (and consequently the detection of the user input) and the visualisation on the screen?

1 Like

Exactly.


1 Like