Huge internal input lag (not related to video API)

[vanfanel]

Hi there,

This emulation core has a VERY high input lag problem, as it's at least two whole frames slower to respond when compared to other GBA emulators like mednafen-gba: https://github.com/libretro/beetle-gba-libretro

You can easily see this, since it's not external input lag but internal to emulation. With the gpsp RetroArch core, simply pause the emulator, keep the jumo button in "Wario Land 4" pressed, and advance frame by frame while keeping the jump button pressed. You will see it takes 4 WHOLE FRAMES for Wario to start the jump animation.

In any other GBA emus, the jump animation starts on the second frame.

Could it be looked into, please? This emulator is the only one that allows fullspeed GBA emulation on ARM platforms like the Raspberry Pi, even in low-latency mode.

[ghost]

quick glancing and testing of code, it indeed has additional 1 frame of input lag. it seems like its doing most of its stuff at the end of the blank period. https://github.com/libretro/gpsp/blob/master/main.c#L230

moving switch_to_main_thread(), update_gbc_sound(cpu_ticks), gbc_sound_update = 0 to run during the start of vblank or during the transition from vrefresh to vblank should remedy this, of course i have not looked deeply switch_to_main_thread() does and how it would affect other timings (vbam is writing input,video and sound during start of vblank)

in theory (assuming no complications of timing and whatnot) after a quick edit and testing, those routines should probably be moved here (within this branch but placed at the end): https://github.com/libretro/gpsp/blob/master/main.c#L211

[inactive123]

I think now that libco has been removed thanks to @davidgfnet it's probably time to do another test.

[davidgfnet]

I tested this with a small ROM I created. The current core has a latency of 2 frames (that is, if you press a button in frame 0, the game reacts on frame 2, minimum you can have is obviously 1 (well not really since you can potentially update halfway rendering)). In my test I simulate a game that updates the screen when a button is pressed. The events are processed right after vblank and updated for the next frame. I'm surprised that you saw 4 whole frames, however we do not know how many delay frames this game has in original hardware (very likely is not 1). We can indeed try to arrange things a bit and get 1 frame back, but that's all you are gonna get.

[davidgfnet]

Im closing this. If anyone is interested in checking the latency on GBA emus you can use this ROM: https://anonfiles.com/zfE3xft4u6/latency_gba Yeah it's super small. Just press Start and screen color will change. You can literally measure the number of frames it takes for it to change and you got your input latency :)