Pre-configured 1-Frame of Lag ShmupArch With Video Guide

This is the main shmups forum. Chat about shmups in here - keep it on-topic please!
User avatar
KaizaCorp
Posts: 96
Joined: Sat Oct 22, 2016 6:43 am
Location: SK, Canada

Re: Pre-configured 1-Frame of Lag Retroarch Ready with Vid G

Post by KaizaCorp »

Tatsuya79 wrote:Thanks to FrozenFish24 we now have a work-around that makes run ahead 2nd instance works for FBA.
You can compile RA with what is mentioned in that thread I linked, or here is a RetroArch exe for windows x64 with the modification.

...
Thanks for putting up the exe with the modification!

While it does sound way better for Battle Garegga, I tried testing the input lag by advancing frames with the modified exe (with other games as well) and it seems to stop the input each frame! E.g. I hold a direction, the input moves the ship, then stops for a frame, then moves the next.

Is this happening for anyone else?
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag Retroarch Ready with Vid G

Post by Tatsuya79 »

I don't have this problem.
I'm not using the package from the 1st post though, just a complete updated retroarch installation with that exe on top.

You can try moving away what can be interfering such as retroarch.cfg (it will generate a new one with default settings) and the content of the config folder.
User avatar
KaizaCorp
Posts: 96
Joined: Sat Oct 22, 2016 6:43 am
Location: SK, Canada

Re: Pre-configured 1-Frame of Lag Retroarch Ready with Vid G

Post by KaizaCorp »

Thanks for checking!

I had just replaced my exe with the modified one and noticed this. I downloaded the updated version of the preconfigured package (ShmupArch Version 2) and it seems to be working great! So it must have been something with my previous settings.
Last edited by KaizaCorp on Sat Sep 22, 2018 7:12 pm, edited 1 time in total.
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by Tatsuya79 »

The problem with run ahead has just been fixed in FBA itself so you won't need a particular version or retroarch now.
It's not in the updater/buildbot yet when I'm writing this though (it should say 7c79ba9 on the bottom when using fba in xmb menu, or something coming after it in the git commit flow).

edit: It's there, retroarch -> online updater -> core updater -> Arcade (FB Alpha).
Last edited by Tatsuya79 on Sun Sep 23, 2018 8:59 am, edited 1 time in total.
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by SWZ »

Thanks for all the information Tatsuya!
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by Tatsuya79 »

Well, you can update retroarch too now as Dwedit (who made the run ahead code) has just fixed the problem of performance loss over time.
So if you update FBA and RA it should be pretty solid now with run ahead 2 instances.
User avatar
KaizaCorp
Posts: 96
Joined: Sat Oct 22, 2016 6:43 am
Location: SK, Canada

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by KaizaCorp »

That's awesome! How to update FBA and RA? Via the core updater, or do I need to compile an exe for RA?
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by Tatsuya79 »

FBA in the online updater yes.

For retroarch you can get 2018-09-23_RetroArch.7z from here and perhaps the redist.7z you unzip in RA folder if you didn't update for some time.
Or just the big RetroArch.7z with everything.
User avatar
KaizaCorp
Posts: 96
Joined: Sat Oct 22, 2016 6:43 am
Location: SK, Canada

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by KaizaCorp »

Got it! Thank you!
User avatar
poptart
Posts: 68
Joined: Fri Jul 27, 2018 11:20 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by poptart »

Tatsuya79 wrote:The problem with run ahead has just been fixed in FBA itself so you won't need a particular version or retroarch now.
just to clarify incase im misunderstanding, there's a fba stand alone with the same run ahead no lag feature? where do i get that?
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by Tatsuya79 »

poptart wrote:
Tatsuya79 wrote:The problem with run ahead has just been fixed in FBA itself so you won't need a particular version or retroarch now.
just to clarify incase im misunderstanding, there's a fba stand alone with the same run ahead no lag feature? where do i get that?
Nope, I was talking about the FBA core in retroarch.

Run Ahead is a retroarch feature, I don't think any emulator got it implemented atm.
User avatar
poptart
Posts: 68
Joined: Fri Jul 27, 2018 11:20 am

Re: Pre-configured 1-Frame of Lag ShmupArch Version 2 Update

Post by poptart »

Tatsuya79 wrote:
poptart wrote:
Tatsuya79 wrote:The problem with run ahead has just been fixed in FBA itself so you won't need a particular version or retroarch now.
just to clarify incase im misunderstanding, there's a fba stand alone with the same run ahead no lag feature? where do i get that?
Nope, I was talking about the FBA core in retroarch.

Run Ahead is a retroarch feature, I don't think any emulator got it implemented atm.

ok thanks, it'd be nice if it does make it to fba etc one day as retroarch ui is garbage imo, they need some serious Dieter lams philosophy to their design.
User avatar
OmegaFlareX
Posts: 884
Joined: Tue Jan 25, 2005 10:15 pm
Location: Virginia, USA

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by OmegaFlareX »

I'm not using ShmupArch but I have questions about some of the options in the RA latency menu. Hopefully someone here can help me out:

The next two under Hard GPU Sync toggle (Hard GPU Frames, Frame Delay), what are these and how do they affect the input lag? In your video guide they're both set to zero but the tooltip says they could also reduce latency? My computer seems to tolerate 8 or 9 ms of frame delay before weird stuff starts to happen.

What do the Poll Type Behavior settings do? The tooltip here is really vague. I assume "Early" has the least amount of latency?

From what I understand you're supposed to measure the input lag yourself then set the runahead frames to n-1, 2 is generally enough for console cores (NES/MD etc), and having the 2nd instance on removes audio problems. Please correct me if I'm wrong.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Mark_MSX »

OmegaFlareX wrote:I'm not using ShmupArch but I have questions about some of the options in the RA latency menu. Hopefully someone here can help me out:

The next two under Hard GPU Sync toggle (Hard GPU Frames, Frame Delay), what are these and how do they affect the input lag? In your video guide they're both set to zero but the tooltip says they could also reduce latency? My computer seems to tolerate 8 or 9 ms of frame delay before weird stuff starts to happen.

What do the Poll Type Behavior settings do? The tooltip here is really vague. I assume "Early" has the least amount of latency?

From what I understand you're supposed to measure the input lag yourself then set the runahead frames to n-1, 2 is generally enough for console cores (NES/MD etc), and having the 2nd instance on removes audio problems. Please correct me if I'm wrong.
Hey man thanks for asking your question.

So those two options in the Latency menu you are talking about are Hard GPU Sync Frames and Frame Delay. I can understand why you would be curious about these settings, as their purpose is ambiguous for sure. So what the Hard GPU Sync Frames does (I am pretty sure) is allows your CPU to run ahead of your GPU to help reduce screen tearing, which is nice. However, this is pretty damn taxing on the CPU so I left it at zero so that people with average gaming computers aren't getting performance problems, as run-ahead is already taxing on the CPU. However, if your computer is a beast, feel free to turn these frames up to reduce screen tearing without any input lag penalty.

So the other option, Frame Delay, is enemy #1 to the purpose of shmuparch. It also reduces screen tearing, but at the cost of adding latency. So, neither of these options improve input lag, but the frame delay option can increase the lag.

Poll type behavior is funky and even I struggle to quite understand how it works in practice. HOWEVER, I did do real time testing of input lag with the different options, and early performed 1 frame of input lag in a real-time test (versus just a frame advance test). So I trust Early as the best setting for Shmuparch.

As far as measuring input lag yourself, yes this is the best practice using the frame advance feature. However, I have already created config files for pretty much all the CAVE, Psikyo, and Raizing shmups, so you don't need to worry about doing that with these games, it's already done.

As for your studdering issue, I have a few ideas that might help. For one, if you have the hard GPU sync frames above 0, that is probably it as that setting is very CPU intensive. If you are still getting stuttering with run-ahead, it could be a matter of your CPU not being powerful enough to smoothly run the feature, as it is very intensive. For example, a Nintendo Switch and PS3 are only able to perform 1 frame of run ahead effectively. Lastly, it may be possible that you are over-running some of your games, and have the setting too high.

Hope this helps! :-)
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by SWZ »

OmegaFlareX wrote:I'm not using ShmupArch but I have questions about some of the options in the RA latency menu. Hopefully someone here can help me out:

The next two under Hard GPU Sync toggle (Hard GPU Frames, Frame Delay), what are these and how do they affect the input lag? In your video guide they're both set to zero but the tooltip says they could also reduce latency? My computer seems to tolerate 8 or 9 ms of frame delay before weird stuff starts to happen.

What do the Poll Type Behavior settings do? The tooltip here is really vague. I assume "Early" has the least amount of latency?

From what I understand you're supposed to measure the input lag yourself then set the runahead frames to n-1, 2 is generally enough for console cores (NES/MD etc), and having the 2nd instance on removes audio problems. Please correct me if I'm wrong.
Hard GPU Frames controls the size of the buffer (in frames). You want to set it as low as possible. The whole point of Hard GPU Sync is to eliminate or reduce the size of the back buffer.

Frame delay is not something you want to turn on unless you use vsync. Even if you are using vsync, it should be the last thing to set. Frame delay pauses emulation for a certain amount of time (in ms; set in the gui) until just before a refresh. This eliminates the majority of the lag penalty incurred by using vsync in emulators. The highest you can set it to is 15ms, meaning everything happens in the final 1.67ms before refresh. This does nothing without vsync and will cause a significant performance penalty. Expect to need a lot of horsepower to use this in conjunction with the other lag reduction methods. In summary: enabling vsync without any extra buffering will add one frame of lag to your game and frame delay can shave off up to 15ms of that.

The poll type behavior does exactly what it sounds like: it tells RA where in a frame to poll inputs. With it set to early it will poll at the start of the frame; late towards the end. Late will give you the best results here.

As for setting the runahead, the easiest way to do that yourself is by pausing the emulator (with P), holding an input, then pressing frame advance (K) while counting until you see the game react. This will tell you how much internal lag the game + emulator has. If the game reacts in 2 frames, you set runahead to two for that game. Repeat the test and you should see the game react on the next frame always.
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Tatsuya79 »

What SWZ said is the right answer.
The frame delay setting is a really precise "lag reduction" method (by around 1ms step) and its sweet spot will change with different games and cores you're using.

All those settings have to do with V-Sync and I noticed Mark_MSX is disabling it in its main cfg hence why he's confused about them.
At the beginning RA was made around the concept of vsync, not dropping frames, and deviating the timings to the monitor refresh you're using (in the limit of the audio max skew defined in settings>audio).
So I wouldn't disable that by default.

The other option I added in settings>frame throttle>exact sync to core will only work best with variable refresh screens that can deal with a particular timing or you'll have visible tearlines.
Last edited by Tatsuya79 on Mon Nov 19, 2018 10:46 am, edited 1 time in total.
User avatar
OmegaFlareX
Posts: 884
Joined: Tue Jan 25, 2005 10:15 pm
Location: Virginia, USA

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by OmegaFlareX »

Awesome, thank you for the answers. I have to have vsync enabled because it's the only way I can get smooth movement in RA. Hard GPU sync by itself (without vsync enabled) does nothing for screen-tearing. Adaptive Vsync also doesn't seem to work by itself.

So I guess I had the right idea about frame delay since I use vsync, I want that as high as it can go, and my system seems to tolerate 8ms well. If I'm understanding correctly, that cuts the vsync penalty roughly in half, in exchange for a big performance hit? For what it's worth, in other emulators/games (such as Mushi on steam) I've noticed enabling vsync seems to add much more than 1 frame of latency, it's more like 4 in terms of real-time feel.

I was playing MD Truxton yesterday with 2 frames of run-ahead. I definitely noticed some slight weirdness in sprite movement. It's really subtle and took me a while to see it, but the player ship will shift one pixel in the opposite direction when I'm finished moving. This was completely unnoticeable with 1 frame of run-ahead, so I'll have to leave it at that.

Also, run-ahead does NOT work well with core overclocks to reduce slowdown. Any time I'd encounter slowdown normally, the sprites would start jumping all over the place so I had to turn the overclock off. Removing the sprite limit seems ok.

e: I can do max 2 frame delay on the bsnes-mercury-accuracy core. 2ms is not noticeable and probably not worth the performance hit. One might be able to say the same about 8ms for NES/MD.
Last edited by OmegaFlareX on Mon Nov 19, 2018 1:47 am, edited 1 time in total.
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by SWZ »

OmegaFlareX wrote:For what it's worth, in other emulators/games (such as Mushi on steam) I've noticed enabling vsync seems to add much more than 1 frame of latency, it's more like 4 in terms of real-time feel.
That's true, I'm afraid. This mostly stems from additional unnecessary buffering. Realistically only one frame ever needs to be buffered for vsync but your video drivers will decide how many for you. The application/game itself gets no control over this back buffer whatsoever which is why you can use what amounts to a hack (read: Hard GPU Sync) to eliminate this back buffer (at least for the opengl api in RA). This is not a problem anymore for games using lower level APIs like Vulcan.
User avatar
OmegaFlareX
Posts: 884
Joined: Tue Jan 25, 2005 10:15 pm
Location: Virginia, USA

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by OmegaFlareX »

SWZ wrote:That's true, I'm afraid. This mostly stems from additional unnecessary buffering. Realistically only one frame ever needs to be buffered for vsync but your video drivers will decide how many for you. The application/game itself gets no control over this back buffer whatsoever which is why you can use what amounts to a hack (read: Hard GPU Sync) to eliminate this back buffer (at least for the opengl api in RA). This is not a problem anymore for games using lower level APIs like Vulcan.
Fascinating! The Nvidia drivers do have an option called "Maximum Pre-rendered Frames" which I've always set as low as it can go (1). This does make a noticeable difference for the better when using vsync. I'd love to get a G-sync monitor and ditch vsync altogether but right now they are useless for windowed stuff (MS broke it a while back and has yet to fix it), and I play nearly all my PC games in windowed fullscreen for easy alt-tabbing (RA is the only thing I run in fullscreen mode). Actually, I think DX12 ditches fullscreen modes altogether? That is the case with the MMO I play.
User avatar
munchiaz
Posts: 63
Joined: Fri Nov 04, 2011 4:57 am

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by munchiaz »

I just set this up a few days ago. Thanks for your hard work, and the videos explaining the process. Also looking through the thread, should I be also adding the new stuff that Tatsuya79 posted? Also, What is the frame rate supposed to be for Ketsui? I ran it and it displayed as 59.2, but it felt a lil fast to me
User avatar
blackoak
Posts: 1066
Joined: Sun Feb 20, 2011 12:43 am

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by blackoak »

Nice work on this, I've been enjoying Batrider this way. I seem to get the best results, visually, with vsync on (and i assume that doesnt destroy the 4 frame reduction from the run-ahead? it still feels better than vanilla mame or shmupmame). I'm running it on a 120hz tv monitor... would there be any interactions/settings there I should be aware?
shmuplations.com - translated game developer interviews and more
support shmuplations on patreon!
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Mark_MSX »

blackoak wrote:Nice work on this, I've been enjoying Batrider this way. I seem to get the best results, visually, with vsync on (and i assume that doesnt destroy the 4 frame reduction from the run-ahead? it still feels better than vanilla mame or shmupmame). I'm running it on a 120hz tv monitor... would there be any interactions/settings there I should be aware?
Yes even with v-sync, it should be more responsive. That's an interesting question about the 120 hz monitor. I haven't figured it out yet, but I have been experimenting with ways to possibly run the emulator at 120 fps without speeding up the gameplay. No dice so far, but I believe its possible because I achieved it in grooveymame. However, one feature that I do know works on a 120 hz monitor is a video setting called "black-frame insertion" which makes the scrolling smoother and removes ghosting. I'd encourage you to check it out and see what you think.

Also, I'm working on a new version right now that has improved settings overall, in my opinion, so keep an eye out for that.

Cheers man! :-D
User avatar
nesrulz
Posts: 181
Joined: Wed Nov 13, 2013 6:01 pm

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by nesrulz »

Mark, thank you for doing a great job.

Cheers!
User avatar
Tatsuya79
Posts: 149
Joined: Tue Jan 07, 2014 10:29 am

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Tatsuya79 »

Well, it seems MAME in retroarch has the same response time as stand-alone after all.
I recorded them side by side with OBS and they react the same.
https://github.com/libretro/mame/issues ... -537440359

So MAME could probably save 1 frame somehow if I'm right.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Mark_MSX »

Hey my dude :-)

Sounds about right! Quiet a bit has changed since I initially made this video/post. I've also noticed that FBA/FB Neo have cut down a frame of input lag (without run ahead), since I first started working on ShmupArch. Sounds like it might be worthwhile to look into the MAME core again for the later shmup titles (Mushi and such). I can't wait for the day that the MAME core gets some sort of save state / run ahead support, that will be a beautiful day for sure.

Cheers!
User avatar
OmegaFlareX
Posts: 884
Joined: Tue Jan 25, 2005 10:15 pm
Location: Virginia, USA

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by OmegaFlareX »

Each individual RA core needs to specifically support the run-ahead feature. Not all of them do.

I reformatted my PC about a month ago with a new build of Windows, and the default xaudio driver stopped working for me. Switching to openal or dsound restores functionality but using those cuts the UI FPS to 30 or less. Weird!
User avatar
pbsk8
Posts: 52
Joined: Tue Oct 29, 2013 11:37 pm

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by pbsk8 »

is the version 5 on first post still the latest version?

Thank you for this
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by Mark_MSX »

Hi there,

Yes, the link in the first post (which currently gives you version 5) is the latest version. I update the versions on that link so that people aren't have to deal with old versions and such.

Cheers!

Mark Lewis
User avatar
tnc
Posts: 81
Joined: Sun Jun 03, 2018 11:31 am

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by tnc »

So in Retroarch if you set Vsync on (because there is no other way to get rid of tearing on a 60hz lcd, right?) you get one more frame of input lag and if your game is something other than 60hz, the speed will change, right? But if your CPU can handle it, that one more frame of input lag can be eliminated by increasing the number of frames to run ahead setting by one, no?
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag ShmupArch With Video Guide

Post by SWZ »

tnc wrote:So in Retroarch if you set Vsync on (because there is no other way to get rid of tearing on a 60hz lcd, right?) you get one more frame of input lag and if your game is something other than 60hz, the speed will change, right? But if your CPU can handle it, that one more frame of input lag can be eliminated by increasing the number of frames to run ahead setting by one, no?
That's incorrect. You will get one or more frames of input lag by setting vsync on. The amount of lag depends on your system and video configuration. If you are using the opengl api for the video, which I believe is the default, configuring vsync in addition to GPU hard sync will get it down to a minimum of one frame. You can reduce the lag penalty of vsync further by additionally configuring frame delay. See my earlier post in this thread for an explanation of how to configure those and in which order.

Run ahead will remove only the combined internal lag of the emulated game and emulated hardware.

The behavior of some emulators is to speed up a game < 60hz to match your 60hz monitor. This is to avoid some obvious synchronization issues that could occur viewing a 54hz game on a display which refreshes at 60hz, i.e. juddering. Retroarch does this by default but you can configure the speed of emulation manually with an override. Mark has already done this for you in his configs.
Post Reply