Does max_swapchain_images have any effect in Windows? The blog post about it only mentions Linux.
I don’t actually know for sure, but it looks like it only applies to OpenGL in a KMS/DRM context, which isn’t available in Windows.
EDIT: oh yeah, from maister: “Only KMS. It is not possible to control this in regular GL. GPU Hard Sync is similar, but the hacky version.”
I tried changing it to 2 but couldn’t notice a difference. I know there are games that allow you to change between double and triple buffering, so it should be possible. It would be nice for the 1 frame input lag reduction.
Edit: saw the your edit. Hmm, maybe I’ll make a Lakka flash drive.
do you have access to a camera that can record video at a high frame rate (> 60 fps)? if so would you be willing to run some tests on sonic 1 in sonic jam on your saturn in order to determine the actual avg response time of the game? while having a led wired up to a controller (like brunnis has been doing) certainly aids greatly in ones ability to get accurate readings quickly, it can be done w/o too. if you hold the controller in front of the display you’re recording and get enough samples (say 20-30 or so), i bet we could get an accurate enough reading to help determine where the problem lies, if it’s the emulator or not. if you plan on doing this pls let me know as i’ll give you some tips that might help you get more accurate readings.
edit: although i can tell you i don’t have high hopes that there’s really any room for improvement to remove latency from mednafen saturn; well, besides general optimizations that may eventually reduce the cpu load and allow you to run it with more aggressive settings. of the saturn emus out there that allow you to frame step them (yabause via libretro and mame) mednafen saturn appears to be the quickest to show a response to inputs. my guess is that it’s already doing everything it can and that the problem lies either in how the hardware works or the software itself… but again, anyone who’s able to do testing could at least confirm this fact for us.
@brunnis : wow, that’s a comprehensive post, it’s so much clearer in my mind now, thanks 
So a NUC seems to be a great solution, meanwhile.
@all : do you all use TN monitors or do some of you use (A-M)VA / IPS monitors ? The latter have better contrast, better colours, better angles etc. but not as good latency. Do it matter for oldschool 2D gaming ?
I have an IPS monitor but it also supports Gsync so I guess the lag is compensed by the Gsync function.
I’d say pixel response time is less of an issue than input lag (I tend to view them as different things). A longer pixel response time blurs the picture slightly, but generally doesn’t affect playability much (unless it’s really bad). It’s true that VA and IPS monitors usually have a few milliseconds longer response time than TN, but whether or not the extra blurring is viewed as distracting or not varies from person to person. It’s also important to note that the monitor’s input lag, i.e. the processing delay between input and start of pixel change, isn’t worse on VA/IPS than TN. Input lag is dependent on the design of the specific monitor model and not the display panel technology.
I personally use an IPS monitor (HP Z24i) which appears to have very low input lag. I also use a plasma TV, which has pretty high input lag (~2.5 frames) but quick pixel response time.
what snes core and what games are you talking about, like only super fx games or others as well?
can’t wait to see your results testing various setups on the pi, it’s very much appreciated!
I used the snes9x2010 core. Primarily tested with Yoshi’s Island, so, yes, SuperFX. Ran some tests with Super Mario World as well and believe I had some slight hiccups but nothing too serious.
Come to think of it, I might as well upload the code and people can tinker with the setting if they want to. It will probably work fine for NES and most SNES games on a Pi 3 and emulator and game specific settings can be used to just apply it where it works.
Thanks!
@Brunnis
forgot to ask you, hopefully you’ll see this question b4 you log off
are you doing your tests with audio_sync enabled? if you are might i suggest in the future, it might be a good idea to disable it, it’s possible that it could be messing with results slightly / be responsible for some of hiccups you might experience. prob not a big deal, but it’s one less variable to worry about
Created a pull request for the updated DispManX driver: https://github.com/libretro/RetroArch/pull/3815
[QUOTE=e-tank;49299]@Brunnis
forgot to ask you, hopefully you’ll see this question b4 you log off
are you doing your tests with audio_sync enabled? if you are might i suggest in the future, it might be a good idea to disable it, it’s possible that it could be messing with results slightly / be responsible for some of hiccups you might experience. prob not a big deal, but it’s one less variable to worry about[/QUOTE]
Thanks, I’ll keep that in mind. I have been having audio_sync enabled so far.
I don’t have that type of equipment.
All i can share is some words here in this forum. Also, i don’t have Sonic Jam on the real Saturn but i do have Duke Nukem and it’s the first game i usually test. There is a noticeable difference between it and Mendafen Saturn with the highest settings possible (still i can’t manage 0 GPU frames though). For Sonic, i just compared Mednafen Saturn with Genesis GX plus and there was a huge difference in lag (i didn’t even have to use the real Mega Drive).
I really hope some improvements can be done with Mednafen Saturn on that front. It’s the best Saturn Emulator right now and input lag seems to be it’s only weakness. SSF is also pretty bad. Not many options here.
The pull request has been merged. Compile RetroArch from source on your Raspberry Pi and set video_driver = “dispmanx” and video_max_swapchain_images = 2 to test. Be prepared for anything demanding to stutter or run slow, though. Raspberry Pi 3 highly recommended.
EDIT: I also updated my previous post with settings recommendations to include info about using video_max_swapchain_images = 2 on the Pi.
I’m sorry if this has been addressed (couldn’t find it), but currently, which cores have these inpug lag improvements applied on the main branches? I know Snes9x was being worked on, but now that there’s a Snes9x 2010 and a Snes9x on the updater, but no longer a Snes9x Next… I’m a bit lost.
They all have it or didn’t have that issue.
Snes9x2010 = Snes9x Next Snes9x2005 = CAT SFC Snes9x2002 = Pocket Snes
older = faster = less compatible
[QUOTE=Tatsuya79;49322]They all have it or didn’t have that issue.
Snes9x2010 = Snes9x Next Snes9x2005 = CAT SFC Snes9x2002 = Pocket Snes
older = faster = less compatible[/QUOTE] Are you sure? Out of the snes9x based cores, I have only reviewed and fixed snes9x and snes9x2010. But maybe someone else looked into the others?
I thought you said they were OK but I’m probably mixing it up with the NES cores, my bad.
Heh, that’s really promising ! 2 fewer frames of lag on the Pi, on par with a regular PC then ! Games will be definitely more playable.
Is there really no way to add scanlines (overlays) in dispmanx mode ?
Awesome improvements, thanks !
For those of you that want to try video_max_swapchain_images = 2 on the Raspberry Pi with DispManX: I have noticed that there’s a big difference in smoothness when using force_turbo=1 in /boot/config.txt. With the default setting of 0, the Raspberry Pi will downclock itself to 600 MHz whenever it feels the processor load is low. With video_max_swapchain_images = 2, the Pi evidently decides to downclock itself periodically, which causes major hiccups. Even Super Mario World, which is pretty easy to run, had obvious performance issues while playing just half of the first level.
The good news is that setting force_turbo=1 seems to have solved those issues quite effectively. I played through a couple of levels of SMW and SMW2 and didn’t notice any issues. The intro and menu in SMW2 are slow, though, but those are quite demanding. force_turbo=1 pins the Raspberry Pi’s CPU to its maximum frequency at all times (1.2 GHz). There are rumors that this can void the warranty of the Pi, but that’s not true. It’s only when this setting is used in conjunction with overclocking that you may void your warranty.
I will update the settings guide a few pages back with the info about the force_turbo setting.
[QUOTE=bidinou;49366]Heh, that’s really promising ! 2 fewer frames of lag on the Pi, on par with a regular PC then ! Games will be definitely more playable.
Is there really no way to add scanlines (overlays) in dispmanx mode ?
Awesome improvements, thanks ![/QUOTE] You’re welcome! Regarding scanlines and such using DispManX: Not possible, as far as I know.
Brunnis, I’m re-reading your post from page 36 and you recommend Linux w/KMS as the best for low latency, but the first post in this thread suggests that Windows 10 has the lowest latency.
Has any of this changed?