retroarch does have an input handler that checks for hotkeys/etc, before it passes your inputs to the emulator, which might add a bit of latency, but it’s pretty simple so i doubt it. you could install retroarch and lr-fba on your PC to see if it’s the same result there?

there’s a couple of other retropie emulators that run neogeo games that might have different results:
lr-mame2003
gngeo
lr-fba-next
(more?)

also, you might get more info at libretro.com/forums as the developers hang out there. let us know what you find :)

there’s an alternative video driver that uses open gl 2.0 rather than open gles. it’s only available as a complete system image I think, so you’d have to install retropie on top of that via the scripts.

seems like a lot of effort but yeah! http://dri.freedesktop.org/wiki/VC4/

EDIT: having re-read your post I’m not sure this would change the compilation stuff anyway!

RetroArch as you have built it will not use SDL 1 btw so you don’t need to install SDL first.

cool progress! is performance near enough the same? I’m curious as to whether dispmanx improves performance on some of the more intense 2d games, as I presume it should as it’s closer to the hardware than the regular gl driver?

I haven’t tested on normal Raspbian yet honestly only because my results have been so good with RT. Another benefit which may be partially related to RT kernel is that I can successfully run audio latency all the way down to 32ms in Retroarch which is pretty quick! (16ms crackles and distorts)

It took awhile but I finally got a standalone copy of pcsx-rearmed (non retroarch) to compile properly and have been running FF7 what seems like perfectly. I am not getting a lot of the graphical and speed issues I was having in other PCSX versions on other releases. I even had double res textures option running full speed but then the game crashed…

Am going to try and get as many cores/emus as possible running the best it can then try and release a SD card image for you dudes to try. I think it will be really helpful, especially to the competitive fighting game players to have something that is basically as good as anything else with minimal input lag out of the box.

Also I figured out the overscan issue is just my TV not handling 640×480 very well. I have had much better success running 1024×768 to maintain aspect ratio!

ok – looks like it’s something config related triggering it – don’t need a config now as I have a working one and will diff/compare. Cheers.

I do not have a NES core working currently but to be fair I haven’t tried too hard either. Regardless here is my output this is kind of the best I can do over SSH. I can not get the entire console output to go into a file for some reason:

Didn't read whole file: /sys/devices/system/cpu/present.
Didn't read whole file: /sys/devices/system/cpu/possible.
RetroArch [INFO] :: === Build =======================================RetroArch [INFO] :: [CPUID]: Features:
Built: Nov 30 2015
RetroArch [INFO] :: Version: 1.3.0
RetroArch [INFO] :: Git: 3cd7014
RetroArch [INFO] :: =================================================
RetroArch [INFO] :: [CPUID]: Features:
RetroArch [INFO] :: Looking for config in: "/home/pi/.config/retroarch/retroarch.cfg".
RetroArch [INFO] :: Config: loading config from: /home/pi/.config/retroarch/retroarch.cfg.
RetroArch [INFO] :: Threaded rarch_task started
RetroArch [INFO] :: Loading dynamic libretro core from: "/home/pi/.config/retroarch/cores/picodrive_libretro.so"
RetroArch [INFO] :: Environ SET_VARIABLES.
RetroArch [INFO] :: Version of libretro API: 1
RetroArch [INFO] :: Compiled against API: 1
RetroArch [INFO] :: Environ PERFORMANCE_LEVEL: 0.
RetroArch [INFO] :: Environ GET_LOG_INTERFACE.
RetroArch [INFO] :: Environ SET_DISK_CONTROL_INTERFACE.
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_input1:
RetroArch [INFO] ::     3 button pad
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_input2:
RetroArch [INFO] ::     3 button pad
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_sprlim:
RetroArch [INFO] ::     disabled
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_ramcart:
RetroArch [INFO] ::     disabled
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_region:
RetroArch [INFO] ::     Auto
RetroArch [INFO] :: Environ GET_VARIABLE picodrive_drc:
RetroArch [INFO] ::     enabled
RetroArch [INFO] :: libretro core requires content, but nothing was provided.
RetroArch [INFO] :: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.

Here is my config file: http://fpaste.org/296043/93866914/

Just to confirm you are using RPI 2?

https://github.com/libretro/RetroArch/issues/2503

threaded video makes a big difference for performance for some stuff – at least with the gl driver (and for people with rpi1). We changed the default to “false” for a retropie release and there were lots of complaints regarding performance. It is easily switchable via our “config editor” from the retropie menu.

from retroarch.cfg template:

Use threaded video driver. Using this might improve performance at possible cost of latency and more video stuttering.

I am adding the dispmanx driver to our retroarch build (you will need to build from source of course in retropie-setup). I will add an option for switching config in the config editor.

Wow thanks so much buzz! Did not think I would ever make such a major impact!

One thing I did test while doing all of this was loading my own compiled Retroarch build (dispmanx enabled and on) through EmulationStation and it would just close and bring me back to the frontend.

Figuring that one out is a bit above my head but I just wanted to put it out there.

Hey furntree! Great job on fiddling with this. I’m in a similar position where input lag is killing the experience for me (getting a 7 frame lag on the NES/SNES cores (plus the 2 frames my TV adds!))

Any chance you could upload an image of what you’ve got working so far? I’m curious to know if the input lag can be reduced to a level that I would personally find acceptable. 9 frames just isn’t good enough for me. If I can get it down to 2 (plus the 2 from my TV) I’d be more willing to put more time into getting RetroPie up and running. As it stands, the stock image/script installer just don’t cut it imo.

Don’t get me wrong, I appreciate the effort that’s gone into this project and understand that the technical problems are actually related to Libretro/RetroArch, but I don’t really want to invest more time into this if it isn’t possible to reduce the input lag.

Hey dankcushions! Ok, cool. I’ll have another fiddle around with it at some point and see what happens.

Out of pure curiosity, I ended up downloading the RT kernel Raspbian that furntree mentioned, compiled RetroArch using his custom flags then proceeded to download/compile FCEUmm and see what happens. Performing the same SMB3 test I did in my other post I ended up shaving 1 or 2 frames off the input lag (mostly 2, sometimes 1, but this could’ve been a camera/TV refresh problem – my test isn’t exactly scientific!).

While that brings my lag down from 9 frames to 7 (or, 7 to 5 if you deduct the 2 frame lag my TV causes), it’s still a couple of frames off what furntree has accomplished. Granted, I’m testing a different core and I’m not exactly sure what his setup is. This is why I wanted an image of his SD. Firstly I’d want to run my own test using his setup. Secondly, it’d be interesting to use his setup as a starting point then, working backwards, start changing the settings to match my own and see which (if any) start causing lag.

btw, you’ll have to excuse my lack of knowledge on all of this. I’m still relatively new to the world of Linux. I’ve completed a few other Linux-based projects (NAS server, Hyperion box etc) but they were all mainly just a case of copying/pasting commands and hoping for the best!

Hey guys didn’t see this popped up again!

I actually gave up on this project because I couldn’t find a reliable way of getting it to work with low latency input. The best I was able to get was by using dispmanx as the display driver and linuxraw instead of udev for joystick inputs. The problem with linuxraw is…..no Xbox 360 pad support.

I also used the realtime kernel, but beyond that I didn’t really do anything too fancy. Keep in mind in that video I am running fba libretro running Street Fighter Alpha 2 test mode. Games you test may or may not have inherent latency to them.

If you are looking for a pocket sized computer to bring around with you for fighting games like I am. You might want to look into the UP Board running Windows:

Homepage

Best of luck!