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
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

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

Post by Mark_MSX »

Hi Everyone,

So I have been collaborating with an awesome member of my dischord, pmp, on a really cool project. It is a preconfigured zip of Retro Arch with the settings all calibrated to give 1 frame of input lag for a number of popular shmups. Just unzip, config your controller, and you should be good to go! Now, due to the limitations of the FBA core, later CAVE releases and stuff like that are unsupported, but this is an excellent option to play shmups like DDP, DOJ, Ketsui, Esp. Ra. De. most of the Psikyo shmups, Batrider, and even Battle Garregga! As well as a bunch of other shmups from around that time period.

All of these games now have been configured to run at their proper framerates, have full save-state support, and 1 frame of input lag. This 1 frame of lag is not in addition to the game's native lag, but instead just 1 frame, no matter the game's native lag. Essentially, this means all games are more responsive using this method than they would be off the pcb.

As far as downsides go sadly, Garegga has an issue with the music being slowed down to half speed (which may or may not bug you). Personally, I'll happily trade slowed down music for 2 frames of input lag reduction and save states, but that's just my opinion.

Anyway, this is still a work in progress, and should improve as Retroarch improves, but for now I still think it is definitely worth checking out. Jaimers said it makes a huge difference with DDP, and I definitely agree.

*UPDATE*

Not too long ago I released version 2 that included a fix for the Battle Garegga audio. Unfortunately, I got reports that the updated version was having problems with frame-rate stuttering. So, until all the bugs in version 2 are ironed out completely, I will have version 1 remain that public version. If you have the version 2 that I released, I'd recommend returning to version 1.

Version 1 Download

https://drive.google.com/open?id=1tgSXv ... 6O8YoMwYQl

(The download link will say version 2 at first, but when you go to download it will be version 1. This is because I replaced the file in the version 2 link).

Also, here is a video guide I put together to show you the process of setting things up. I also talk about various details of the emulator that are pretty interesting. This guide also explains how turbo fire works in retroarch, which is a little strange.

https://youtu.be/4eytz2nHC_I

Also, here is a quick guide on how to rotate video to play in Tate:

https://www.youtube.com/watch?v=lXKJeehWErQ
Last edited by Mark_MSX on Mon Sep 24, 2018 3:59 pm, edited 7 times in total.
User avatar
Mantrox
Posts: 355
Joined: Mon Nov 25, 2013 11:03 pm

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mantrox »

Thanks for the work.
When my house renovations are complete, i'll get a setup inside my cab and try this out.

Is the 1 frame of input lag consistent across all games or is it dependant on anything else?
Is this frame of lag added to the games native lag?
User avatar
Stevens
Posts: 3799
Joined: Thu May 01, 2014 11:44 pm
Location: Brooklyn NY

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Stevens »

This is bad ass. Amazing work!
My lord, I have come for you.
User avatar
Shelcoof
Posts: 1520
Joined: Mon Nov 03, 2008 9:36 pm
Location: Canada

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Shelcoof »

Nice
Will check it out
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

Mantrox wrote:Thanks for the work.
When my house renovations are complete, i'll get a setup inside my cab and try this out.

Is the 1 frame of input lag consistent across all games or is it dependant on anything else?
Is this frame of lag added to the games native lag?
Great question about the lag! I'll clarify this in the original post too. No, the 1 frame of lag is not added to the game's native input lag. Instead, the game, no matter its native input lag, now responds within 1 frame. In essence, this means that all the games emulated have less input lag than their native pcbs. For example, DDP is now 1 frame faster than native (native for that game is 2 frames of input lag), and Battle Garegga is now 2.5 frames faster than the pcb (which is around 3.5 frames of lag).

This effect of responding within 1 frame is consistent across all the games Pmp and I have created configs for, but the way the games have to be configured depends from game to game. This is a summary of how the games are configured, overall:

CAVE = 2 frames of run ahead
Psikyo = 4 frames of run ahead
Raizing = 4 frames of run ahead

Soon I'll make a quick vid to demonstrate how you can check if your game is responding in 1 frame, and if it isn't just let me know on this post here and I will update the config file to where it needs to be.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

Stevens wrote:This is bad ass. Amazing work!
Thanks man! I really appreciate the words of support.
User avatar
dunpeal2064
Posts: 1781
Joined: Tue Nov 23, 2010 9:14 pm
Location: CA

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by dunpeal2064 »

Appreciate you going through the effort to make and release this, will definitely check it out.

Did you have to adjust the lag on a game-by-game basis? And, if so, does that mean you have a list of the games that have reduced lag? And, if no work has been done to the games yet, is it safe to assume they are still playable in their normal state? Just wondering if I can move to just booting this, rather than having multiple instances of Mame, since its been a go-to when I have guests over, but I have to minimize out-of-game complications for their sake :lol:
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

dunpeal2064 wrote:Appreciate you going through the effort to make and release this, will definitely check it out.

Did you have to adjust the lag on a game-by-game basis? And, if so, does that mean you have a list of the games that have reduced lag? And, if no work has been done to the games yet, is it safe to assume they are still playable in their normal state? Just wondering if I can move to just booting this, rather than having multiple instances of Mame, since its been a go-to when I have guests over, but I have to minimize out-of-game complications for their sake :lol:
Hey man thanks for the reply!

Yes, Pmp and I did to through and adjust the games on a game-by-game basis. We basically tried to cover all of the compatible CAVE and Psikyo shmups, as well as Garegga and Batrider. Pmp also did some work on some Toplan shmups. As I get more time to go ahead and add more games, I'll write up a list of all the configured games at this point.

As far as playing games that have not been configured yet, the good news is that they will be more responsive than Mame as the default run-ahead setting is 2 frames. No game that I know of natively has only 1 frame of input lag, so 2 frames will not cause any issues, it just might not be the full lag reduction, but will still be more responsive than pcb. I guess one thing to keep in mind is that, since FBA is an older core than Mame, it does have less game compatibility overall. However, if the game is compatible, I think running it with this build is the way to go, if you are concerned with input lag.
User avatar
ChurchOfSolipsism
Posts: 996
Joined: Thu Sep 25, 2008 12:12 am

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by ChurchOfSolipsism »

holy fuck, mate. Splendid work! :D
n0rtygames wrote:[The wife] once asked me "whats a shoryuken?" so I gave her a real life demonstration. Except she was too close on the spin. So I actually SRK'd her. With full vocalisation too...
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

ChurchOfSolipsism wrote:holy fuck, mate. Splendid work! :D
Thanks man!! Just wanted everyone to get a chance to experience the awesome responsiveness without having to spend hours tweaking settings :-)
User avatar
Harpuia
Posts: 105
Joined: Thu Nov 26, 2015 1:33 am

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Harpuia »

As someone who already uses Retroarch, what are the exact settings being used here?
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

Harpuia wrote:As someone who already uses Retroarch, what are the exact settings being used here?
Hi there!

Here is a video guide I made on how to setup Retroarch for this from scratch. It will show you the settings you need to adjust :-)

https://youtu.be/lvIx_YsAI98
Dochartaigh
Posts: 1519
Joined: Thu Mar 02, 2017 6:53 pm

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Dochartaigh »

Is this meant for 1080p displays, or 240p CRT's? (heard RetroArch offers 240p support now so thought I'd ask).
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

Dochartaigh wrote:Is this meant for 1080p displays, or 240p CRT's? (heard RetroArch offers 240p support now so thought I'd ask).
This build is for 480p - 1080p displays. I also have heard about some 240p support, I could look into configuring one. I did notice a 240p option in the video settings. Maybe try turning that on?
User avatar
Shelcoof
Posts: 1520
Joined: Mon Nov 03, 2008 9:36 pm
Location: Canada

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Shelcoof »

Okay... so I just realized I have no idea how to use this.

A quick guide on how to set things up?
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

Shelcoof wrote:Okay... so I just realized I have no idea how to use this.

A quick guide on how to set things up?
Yes, I 'll make one tonight, good idea.
User avatar
Shelcoof
Posts: 1520
Joined: Mon Nov 03, 2008 9:36 pm
Location: Canada

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Shelcoof »

Oh sweet!!

Really appreciate it!
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by SWZ »

Thanks Mark! You finally gave me an excuse to start playing around with RetroArch.

There is a setting you used that I'd like some clarification on. You enabled GPU hard sync, but I was under the assumption that this did nothing if you play with Vsync off. It is my understanding that the point of GPU hard sync is to reduce the latency penalty of turning on Vsync to within one frame for opengl, which can further be reduced with the frame delay setting. Is there a reason to turn this on without Vsync? Alternatively, is using Vsync with the frame delay setting and GPU hard sync lagless?
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

SWZ wrote:Thanks Mark! You finally gave me an excuse to start playing around with RetroArch.

There is a setting you used that I'd like some clarification on. You enabled GPU hard sync, but I was under the assumption that this did nothing if you play with Vsync off. It is my understanding that the point of GPU hard sync is to reduce the latency penalty of turning on Vsync to within one frame for opengl, which can further be reduced with the frame delay setting. Is there a reason to turn this on without Vsync? Alternatively, is using Vsync with the frame delay setting and GPU hard sync lagless?
Hi man, thanks for the response! So to clarify about using gpu hard sync, what it does is tie the speed of the emulation to the refresh rate of the monitor. This is what allows retroarch to run funky frame rates like, 57.5, accurately and with the least amount of latency. Otherwise, what retroarch will do is push games like DDP to 60 fps, even though the intended framerate is 57.5. The side effect of this, as I'm sure you have experienced, is screen-tearing. This is where v-sync could come in.

To be honest, I have not actually experimented much with using v sync with this setup, because I believe it will introduce lag. The reason why I think this is because, as I understand run ahead, it is pre-processing the game before it hits the display processing step (if that makes sense). Since v sync introduces a form of display lag (by buffering out the odd frame rate to match monitor refresh rate), rather than input lag, I believe run ahead will not be able to negate the delay of the v sync. I would guess it would introduce another frame or so of lag.

However, if the screen tearing annoys you, you could take a game like battle garegga, run it ahead four frames, and then use v sync (which adds some lag back in) and probably end up somewhere around 3 frames of lag. Again though, I have not tested this at all so who knows, maybe it is possible to use run ahead to completely erase the v sync lag.

It's an interesting idea for sure.

Hope this response helps!
User avatar
tomwhite2004
Posts: 319
Joined: Fri Mar 08, 2013 12:13 pm
Location: UK

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by tomwhite2004 »

Mark_MSX wrote:So to clarify about using gpu hard sync, what it does is tie the speed of the emulation to the refresh rate of the monitor.
No, the speed of the emulation is determined by what you enter as your vertical refresh rate in the video options. By default it is 60hz so the dynamic rate control then skews the audio and game speed to match the specified refresh rate.

Hard GPU sync is related to vsync just as SWZ said. When using the open gl backend more frames can be buffered than you want, so this setting allows you to manually adjust how many frames are buffered, if any at all. My understanding that this is only necessary with the open gl backend and is not necessary with vulcan.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

tomwhite2004 wrote:
Mark_MSX wrote:So to clarify about using gpu hard sync, what it does is tie the speed of the emulation to the refresh rate of the monitor.
No, the speed of the emulation is determined by what you enter as your vertical refresh rate in the video options. By default it is 60hz so the dynamic rate control then skews the audio and game speed to match the specified refresh rate.

Hard GPU sync is related to vsync just as SWZ said. When using the open gl backend more frames can be buffered than you want, so this setting allows you to manually adjust how many frames are buffered, if any at all. My understanding that this is only necessary with the open gl backend and is not necessary with vulcan.
Thanks for the clarification man! Good to know.
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by SWZ »

Yes I think the point of hard sync is to remove additional buffered frames that are the fault of the gpu drivers with vsync turned on. This supposedly gives better benchmarks at the cost of latency. Certain video drivers do not buffer additional frames (e.g. vulkan and d3d9ex) without the need for hard sync. Alternatively, it is possible to compile and run RetroArch on linux with KMS support which removes the need for hard sync on the opengl driver. Frame delay should remove the majority of the vsync lag penalty, but I have not done any objective lag tests to prove that it does anything at all.

It also appears that RetroArch does not support runahead with the MAME core which should offer more accurate emulation than the FBA core at the cost of higher overhead. I also noticed that 'use second instance' does not seem to work for certain games using FBA, but otherwise works with that setting turned off.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

SWZ wrote:Yes I think the point of hard sync is to remove additional buffered frames that are the fault of the gpu drivers with vsync turned on. This supposedly gives better benchmarks at the cost of latency. Certain video drivers do not buffer additional frames (e.g. vulkan and d3d9ex) without the need for hard sync. Alternatively, it is possible to compile and run RetroArch on linux with KMS support which removes the need for hard sync with the opengl driver. Frame delay should remove the majority of the vsync lag penalty, but I have not done any objective lag tests to prove that it does anything at all.

It also appears that RetroArch does not support runahead with the MAME core which should offer more accurate emulation than the FBA core at the cost of higher overhead. I also noticed that 'use second instance' does not seem to work for certain games using FBA, but otherwise works with that setting turned off.
Yes, a member of my discord, KaizaCorp, mentioned running into the second instance compatibility problem with a game. If you can, do you mind listing which games you have found that don't work with 2nd instance? I'll go ahead and add that info into the post, so people know.

As far as the MAME core goes, I did a bunch of testing with it and it is awful. You are completely right that it does not support run-ahead (because it doesn't support save states, I believe). Not only that, but the MAME core is crazy laggy. 4 frames for Garegga, versus only 3 frames just using MAME 2.0. So, I think, if you guys are wanting to go the MAME route, grooveymame or MAME 2.0 are much better options than the MAME core in retroarch. That's why I didn't include it in the build, didn't want people to think it was a good option haha.
SWZ
Posts: 9
Joined: Tue Nov 07, 2017 7:13 pm

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by SWZ »

Mark_MSX wrote:
SWZ wrote:Yes I think the point of hard sync is to remove additional buffered frames that are the fault of the gpu drivers with vsync turned on. This supposedly gives better benchmarks at the cost of latency. Certain video drivers do not buffer additional frames (e.g. vulkan and d3d9ex) without the need for hard sync. Alternatively, it is possible to compile and run RetroArch on linux with KMS support which removes the need for hard sync with the opengl driver. Frame delay should remove the majority of the vsync lag penalty, but I have not done any objective lag tests to prove that it does anything at all.

It also appears that RetroArch does not support runahead with the MAME core which should offer more accurate emulation than the FBA core at the cost of higher overhead. I also noticed that 'use second instance' does not seem to work for certain games using FBA, but otherwise works with that setting turned off.
Yes, a member of my discord, KaizaCorp, mentioned running into the second instance compatibility problem with a game. If you can, do you mind listing which games you have found that don't work with 2nd instance? I'll go ahead and add that info into the post, so people know.

As far as the MAME core goes, I did a bunch of testing with it and it is awful. You are completely right that it does not support run-ahead (because it doesn't support save states, I believe). Not only that, but the MAME core is crazy laggy. 4 frames for Garegga, versus only 3 frames just using MAME 2.0. So, I think, if you guys are wanting to go the MAME route, grooveymame or MAME 2.0 are much better options than the MAME core in retroarch. That's why I didn't include it in the build, didn't want people to think it was a good option haha.
There is a bug report for the second instance runahead functionality in the FBA core. There's also a second bug report for additional lag in the MAME core. Apparently RetroArch is adding an additional frame of latency that does not exist in MAME and FBA when those are run as standalone emulators (it's removed with the runahead for FBA regardless). So if DoDonPachi has two frames internal lag in the RetroArch FBA core, it has one frame in FBA standalone. (here and here)

Second instance did not work for me with DoDonPachi Japan.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

That makes sense about the extra lag from retroarch. I 'll have to look into DDP j. Thanks for the heads up!
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 to Go!

Post by KaizaCorp »

For me, the second instance wasn't working with Strikers 1945.
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

KaizaCorp wrote:For me, the second instance wasn't working with Strikers 1945.
That s right. The wierd thing is that it did work for me. Maybe it s a pc demand type of thing, I m not sure. Would you say you have a powerful pc? Any frame rate issues or something?
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 to Go!

Post by KaizaCorp »

If I try to enable the second instance it gives me the error 'Failed to load state. RunAhead has been disabled'.

It shouldn't be a performance issue, I have a Ryzen 5 2600 and a GTX 1070.

This was with the most recent version of RetroArch though (1.7.4)
User avatar
Mark_MSX
Posts: 411
Joined: Mon Mar 05, 2018 6:58 am
Contact:

Re: Pre-configured 1-Frame of Lag Retroarch Ready to Go!

Post by Mark_MSX »

KaizaCorp wrote:If I try to enable the second instance it gives me the error 'Failed to load state. RunAhead has been disabled'.

It shouldn't be a performance issue, I have a Ryzen 5 2600 and a GTX 1070.

This was with the most recent version of RetroArch though (1.7.4)
Interesting, I 'll have to see how the new retroarch performs with the sync changes
Post Reply