shmups.system11.org

So, my go-to has become Retroarch considering its runahead and overall latency reduction techniques just can't be beat.

Bit of a bummer then that some games have issues that nonetheless ruins the experience.

For example, Guwange normally has 3 frames of input lag (this is on the PCB).

It's reduced to 1 frame in Retroarch, however I noticed the game does not properly emulate slowdown and perhaps even the game speed in general (seems a bit faster to me).

I couldn't even get to level 4 without dying in Retroarch, but when I switched to Shmupmame, no problem getting to the end boss (it's been a while).

Anyhow, just wondering if anyone else noticed the same issue in other games and if they have ways of mitigating it (please don't be cheeky and suggest I buy the PCB. I get it. Haha. Funny answer. But seriously).

Don't use Retroarch, use anything else for any platform.

Seconded. GroovyMAME is your friend.

Why? I'm really happy with Retroarch.

Out of the 100 or so games I actually care to play, Guwange is really the only one I've noticed with this issue. But I'm guessing other's with significant slowdown could be just as problematic.

The trouble with that kind of game is the devs used the slowdown as mechanic; a way to increase bullet density/speed while allowing it to be a surmountable challenge. Thankfully not too many games are like that that I want to emulate (most of those I own on the X360).


Regarding Retroarch, it's not just one thing, though lagless (including lagless vsync) is hard to sniff at. It's frankly the most amazing thing I've ever seen in emulation outside of emulation itself.

And well it just ties in so nicely with my frontend setup. Just grab a joystick, press power on my RetroCade and play.


I was looking into GroovyMame as a secondary, but to tell the truth it's taken me a whole week to get my emulation setup working properly. One of the reasons I never went through with it.

And looking around, GroovyMame came with just as much praise as it did scorn for useability.

Most of the complaints were about crashing and difficulty in setting up with an LCD (as apparently it's mainly meant to be used with a CRT).

I'm open to a build that is stupid simple to use like ShmupMame or Retroarch, but otherwise unfortunately ShmupMame is my secondary.

casual coder for groovymame you just download the most recent d3d9ex and then in the mame.ini under the 'CORE SWITCHRES OPTION' category, edit like this
Code:
monitor lcd

that's it, i started using it myself thanks to xyga's help.

No matter what - besides exact 60Hz games - you won't get smooth (= no choppy scrollings) accurate game speeds in games with either emulator unless you care to set up either a CRT, a FreeSync/G-Sync, or an 'unlocked' LCD environment.

As for lag reduction Groovy allows to get close to the real game's pcb lag, not to defeat it and actually play with better response than the original.
The latter is what OP wants so there's probably no point in recommending Groovy to him.

Groovy when understood and running on a fitting hardware setup can achieve playing the games the closest to accuracy (more accurate refresh speed, scrolling, slowdowns, input lag, audio lag, all together) but it requires much more than changing a single line in the .ini, beyond that there are several stages and quite a bit of learning many people are not willing to bother with.

***

Slowdown accuracy is a related but a different topic, MAME's mostly not emulating cpu wait states so a lot of games in the entire library miss natural slowdowns.
And it's not just missing cpu wait states that are involved in the issue, some slowdowns seem to happen only when a game's running at its original refresh rate without being forced to another or buffered (therefore such slowdown will only show in a CRT/Free-Gsync/unlockedLCD environment)
In several cases tweaking the CPU% speed is the only way to more or less get some of these slowdowns back, though not accurately so, just something approaching the real thing.
Cave's cv1k games then are a special case featuring the blitter delay option, but the best values for each game - which you often have to use in combination with a specific CPU% - are not known anyway, so for cv1k until these values are found (maybe never) it's better to not touch blitter and cpu% and just play without the slowdowns, or not play these particular games at all.

For those who would bother to try and find the best approaching blitter+cpu% values, game-by-game, Groovy is the only choice since afaik it's currently the only build that saves the sliders position. Good luck lol, only players who know the games very, very well and having learned them on pcb can do that, and it's likely that not one of them will ever bother with such a massive chore.

This is another thing that makes me reach for Retroarch. I'm not sure how it does it but its vsync is perfect, no choppyness and all but the most minimal lag if you use GPU sync mode.

I looked into G-Sync, but I'm mainly gaming on my TV. Down the line I'm sure we'll all have G-Sync desktop monitors. Definitely the future.



Not exactly. While I'm not a fan of input lag even if it's "baked in", my main intent isn't to eliminate it entirely but rather to compensate for the lag in the chain that I can't account for.

So, for example, my TV has 16ms of input lag (1 frame) and my RetroCade computer has probably ~6ms just to process the USB controller input itself. If I set a game like Guwange to 1 frame of input lag in Retroarch, it's actually 1 frame + 1 frame + 6ms. Which is almost identical to the original pcb input lag. In cases where I surpass the PCB by a long margin (2 frames), I don't exactly get upset about it.

I've been MAME'ing for over 20 years, so I'll take every small victory in beating the system over enforced input lag any day.



I recall this is one of the things I was impressed with with ShmupMame originally. I thought the developer of that did something to the blitter rates to improve emulation accuracy. And I think technically you can adjust them further, but as you say it sounds like a recipe for disaster.



Thanks, I'll definitely give that a shot with that in mind. If I can achieve equal to what I get with Shmupmame (and not dive into another loop of compatibility headaches) by making those changes then I would be quite happy.

Appreciate the helpful comments.

I'm not sure how it performs this honestly, nor if it really does without speeding everything up, haven't investigated nor touched RA in a long time but magical variable refresh does not exist. Have you checked the games actual speed while playing ? (pressîng F11 to make MAME's internal refresh speed meter appear)

I mean Groovy can force vsync to 60Hz and everything will be smooth (increase sync_refresh_tolerance to like 10) and it'll be at the cost of only 1 frame too since it's using d3d9ex. In fact doing that you will even gain access to frame_delay for all games, allowing you to further reduce lag, if your cpu is strong enough.

But similarly all games not 60hz will be sped up, which isn't a big deal when they're close, but pretty annoying for the 58, 56, 54 etc games.

With Groovy though going further if you have a compatible monitor (crt or non-edid-locked lcd) you can achieve sub-1frame vsynced at the exact original refresh, and use Portaudio to reduce audio lag if you wish, all at the same time.
In fact I believe you can do it with RetroArch too to some extent using custom modes somewhere, though only a number of fixed ones, where Groovy+AMD+Emudriver being dynamic automatically support any mode with precision, like a simili-VRR but it's native rates instead of adaptive to a single one.

Of course commercial FreeSync or G-Sync (and soon HDMI VRR) make all this groovy and retroarch lag reduction stuff obsolete, indeed.
Some TVs already support FreeSync.


Sure it's one way of doing it, personally I don't like too much the idea of getting the input to register too far within the game's own time to compensate a laggy chain (chewing 1 frame off any game shouldn't hurt gameplay tho, just a personal belief*) so I tend to the chain first making sure it's as low-lag as possible, monitor, controller, OS and ports, then apply a lag reduction method to push the input as close to the game's as possible.
In any case for doing that, one day if the beam racing (aka frame slice) method becomes a thing in MAME it'll be less trouble for everyone. Still won't compensate for a laggy setup tho. :p

* I've been wondering, do we know for sure that in the game's program running on its intended pcb, the inputs always register after the equivalent of a number of frames has been produced ? after all these old school pcb's aren't frame-based, MAME is. I don't know if it always waits though, since the inputs layer is not the same thread as video.


Not sure what you mean by 'enforced' so just for the sake of precision; where MAME drivers can be considered accurate (not all of them for sure but for now consider the ones that we can trust the most with what we know), as long as we don't have hard data to contradict (direct pcb lag measurements) then in theory these drivers don't produce more lag than the original games running on pcb, so that part of the emulation delay cannot be considered 'enforced', or at least not yet with only claims, it's still officially the legit delay.
It's only the vsync lag on top of that, and our hardware's, that qualifies as enforced/undesirable, but we indeed have the means/tools to eliminate most of it now, whatever the preference is, groovy, retroarch, or free/gsync.


Blitter delay has been in all MAME builds since then, even before in the 'too close' builds, and it doesn't help much. Until some point we had determined a few rather well working values, but later the cv1k driver was optimized a couple of times and that went to shit, today with several games you have to readjust the CPU% down first before using blitter, not sure what to do exactly I've found some rather nicely working settings but there's too much margin for error, imagine the granularity is 1000 and for each game you're supposed to find the best balanced sweet spot, using the two sliders, and that against the original pcb (or a broad collection of reliable quality gameplay videos, worst case)
It'll be a PITA to complete, all that to get only more or less approaching inaccurate slowdown behaviour, again probably nobody will bother to research thoroughly, or by the time it's done MAMEdev will have implemented wait states. We're not talking near future whatever the scenario.


Doing that is just the most basic way of configuring Groovy, you get 2~3 frames better lag performance than baseline MAME, which means only 1 frame remains used to sync, and that's it if you don't do more.
Then - repeating what I've mentioned earlier this post - if you want you can further decrease the lag using frame_delay (in the sliders menu, only from groovy v0.206 because the slider thing was a bit broken before) but by default that will work only for games within +/- 2Hz off 60Hz.
If you wish to expand the number of games games eligible to frame_delay you need to open the mame.ini again and increase the sync_refresh_tolerance value.
The default is 2.0 (2Hz), so if for instance you increase it to 2.5 the 1st gen Cave games will be included.
But again if you do so, pressing F11 ingame you'll see the meter indicate 104% speed, it's the tradeoff (on the plus side the scrolling will be butter-smooth)
Increasing it more like 10 will cover pretty much everything in MAME, but games like R-Type of course will be sped up considerably. Your choice.

With ShmupMAME you get something similar to the default vsynced 1 frame if using ddraw (nb: not sure ddraw is fine in Win 10 or even 8 ), then the sprite buffer hacks hardcoded in the drivers remove yet another frame, but it breaks the video accuracy (sprites layer in many games no longer in sync with the tiles layer for instance, almost unnoticeable in some games, horribly so in others, I suspect it goes as far as breaking proper timings depending on the game, changing the gameplay as a consequence)
IIRC Guwange fortunately seems almost unaffected.
But considering the numerous games that are, the obsolete drivers (mamedev have fixed tons of things since then), and missing games, shmupmame is long past its coolness.
It keeps an advantage in terms of hardware requirement though, since unlike frame_delay the sprite hacks don't cost anything cpu-wise. Also the old style GUI is nice.

I haven't tried it in quite a while, but the main issue I had with MAME in Retroarch is that for the multitudes of games that are non-60hz, the audio was sped up to 60hz and there was no combination of settings I could find that would prevent that. Apparently RA-FBA is better in that regard (see this thread), but FBA is not recommended for emulating arcade games, and doesn't even support a fraction of what MAME does.

For consoles/handhelds and whatever computer platforms, RA is great. Unless they've fixed it since then, it should not be used for arcade since it fucks up the sound.

Run Ahead works only with FBA in retroarch. Mame cores can't use it without issues.

@casaulcoder:
Made the same observation: Retroarch with fba 2012 core screws with speed and slowdown in Guwange.
I recently played some Guwange on the go on my galaxy s7 with an ipega 9087 controller which turns the phone into a pseudo switch console - it's definitely faster on retroarch than mame.
I still like retroarch though - great for cps2 and mega drive on android.

FBA2012 is an older version from that year for slower platforms.
Try with the FBA core without date as it's in sync with upstream and probably more accurate.

I've done extensive testing in the last week and here's what I found.

Main core: fbalpha_libretro.dll
Secondary core: fbalpha2012_libretrol.dll
Special cases: fbalpha2012_neogeo.dll, fbalpha2012_cps1.dll, fbalpha2012_cps2.dll

Most games run in the main core, if it doesn't it usually will in the secondary.

If all else fails, I go for the specific core depending on if it's capcom cps1/cps2 or neogeo.

Nothing else seems to work right for arcade at the moment.

I haven't come across that problem. Most games are over 54hz. At 54hz the difference is 6hz, which in musical terms is only about 20cents off the intended pitch. Which isn't very noticeable.

So it makes me wonder if that's causing your issue. Sound has been fine for me (except Nintendo cores, but that's easily fixed with "run 2nd instance"

Haven't checked, but I'm pretty sure it runs it up to 60hz. I don't think this is unusual considering most monitors don't support oddball refresh rates. Same issue with playing ports on console.



It's an interesting question. Most PCB delay I would assume is input buffering, but maybe I'm totally wrong considering the era and how hard it was to ensure frame timing with limited resources.



I'm not sure either except to say some games have always been ridiculously laggy in Mame. Gigawing, Battle Garegga, etc. Those games have always been unplayable to me. I don't know how much of that was on the PCB, but removing that lag is the only way I could enjoy those games.



Yeah. It's served me well for a long time (and even now to account for the issues I brought up). But looks like it's time to start experimenting with yet another emulator! I'm a bit burned out on experimenting (if you can believe it, I actually want to play these games!) but soon it looks like I'll have to take notes on what you and other's have said and take the plunge into GroovyMame and port that to my main setup.

Instead of quote-replying I'll say this;

There are two fashions of playing with emulation; with a setup limited to 60Hz, and with a setup able to run proper refresh rates.
The former limits the effectiveness of whatever tricks emulators, frontends, and hacks bring, including lag reduction.
Whether you stick to RA and shmupmame, or try GroovyMAME, as long as you're stuck on a limited setup all three will still have almost as many drawbacks as advantages, no sorcery will fix their weaknesses because they can't go around compromising on one thing ot the other.

What you'll gain using Groovy in a limited environement is mainly the advantage to play with an up-to-date build not missing games nor the fixes from mamedev's many years of work, the smoothness and/or speed accuracy will be your choice by your settings as I've detailed, and the lag reduction you can afford will depend on your CPU's strenght, but it will not allow you to compensate for your laggy setup.

Then if you wish to break beyond and use your time and energy to experience next level emulation, it will try your patience - and wallet - no way around it, sorry.

Is it worth it? if your goal is to play a lot and you judge crucial for that to play right, then yes it is, but it is the no-compromise setup rabbit hole, you'll have to give up playing on a laggy 60Hz locked display and buy a lagless one that has the ability to run native refresh rates one way or the other (gsync/freesync, crt, non-edid-locked monitor), probably a new CPU and GPU if what you have doesn't fit the requirements, plus maybe the least laggy controller you can find, etc
Once you get it all working, well, it'll be impossible to go back, because you'll become aware of all the things that sucked before without this.

Note that there are several different setup possibilities, some require less investment, it depends on what you have access to and the level of quality-results you expect.

The way I see it, RetroArch (or even sticking to shmupmame or whatever alt build), is the somewhat brutal and dirty but accessible solution that 'works anyway', for people who don't really care about the details and conventions, or would be annoyed for their own reasons to learn things that might contradict their beliefs and enjoyment. As I've seen well enough so far, some among people like them manage to find limitless energy to oppose and bullshit rather than question and challenge themselves learning new stuff.
Don't get me wrong about RA though, I don't completely dismiss it, simplicity and accessibility are virtues in emulation, after all run-ahead works, and I find the choice of shaders fantastic.

Yeah, I understand and appreciate the help.

A few years back I thought I was just going to buy a CRT, tate it and be off to the races.

Then I reflected on all of the emulation issues still a problem (which much has been fixed with Groovymame it seems as of now), and also looked at my small apartment and realized it's just not worth it.


I ended up buying a "lagless" ASUS monitor. In reality it's probably about 10ms and coupled with Shmupmame it was a revelation. I used to think bullet hell games were impossible until I got that kind of setup.

Now I'm on my main TV which has 16ms of lag but I can't find anything appreciably better on LCD. I wouldn't say it's "laggy" per se. Most TV's are in the 40-80ms range. Those are really laggy. So while it's not perfect, it's fairly close.

That's why I was so enthused about Retroarch because in theory I could eliminate 1 frame lag present on PCB and effectively bring the effective lag to zero sum.

Otherwise I'm a stickler for lag but I realize I have to make compromises somewhere.

It's a frustrating hobby because all I really want is to play these games as close to their originals as possible. Can't afford PCB's and yet don't have the time and space to infinitely tweak a setup.

Unfortunately I can be a bit OCD and perfectionist and it's kept me from actually playing so many times in the past.

Even right now my new OCD is figuring out a convenient way to keep my arcade stick at the right height and stationary.

Stupid shit like that even puts me down the path of tweaking rather than playing. Such is the hobby I suppose. Overall I am thankful I can play any of this with enjoyment at all.

Depends where you found the lag measurements, a lot of displays reviews quote the lag of common diplays at the center of the screen, which means it's not the input lag but the input lag + 1/2 a frame (at 60Hz)
From there substract 8ms and you're closer to the actual input lag of your display.
For instance my own TV is quoted at 14ms, but the actual input lag is -8 therefore 6ms, which is negligible.

Several monitors reviews then, quote the real input lag, so it's important to know where you get the info.

***

You're right about it being an OCD thing, near-perfect emulation isn't required to play well and enjoy.
That's why good console ports are superior, even not 100% perfect they take those concerns away, because there isn't much we can do about the issues anyway.

But you're also right to mention the price of pcb's, if one thing justifies bothering with building a setup that grants a more accurate experience of emulation, it's very well that.
Even if not all MAME drivers are perfect, the amount of them that are still makes it worthwile. I mean, for the price of a single pcb you get a potent fitting pc+display setup.

If some games don't run on the main core that's most certainly because you don't have the right roms set.
It should be 0.2.97.43.

Thanks for the tip.

Honestly this attitude is really pointless and starving you from some good play, learning a game is learning a game so focus your ocd towards that as whatever setup you learn on within reason doesn't suddenly erode if you play on the real thing, i mean we have ntsc-j who plays muchi pork on hardware and on regular mame with no problems whatsoever, strats are strats at the end of the day and the rest is so nuanced you can adapt very quickly, just play the games.

Though a full dedicated setup is indeed dispensable, not using a build that offers means of lag reduction is kind of stupid, because with the official MAME or whatever variant that doesn't feature lag reduction, the total lag in many games will be 5~7 frames, and if played on a laggy display to make it worse it will reach around a ridiculous 10.

So while some will complain that using run-ahead at high settings to defeat even the original game's lag is cheating, oppositely not doing anything to minimize lag is like playing with a useless handicap.

I mean nearly lag-free monitors literally grow on trees these days and don't break the bank, and retroarch/groovy/shmupmame are free, it's also not that hard nor expensive to find a controller or adapter that doesn't add too much lag by itself.

Maybe. Consider that "good play" varies across many subjective factors.

I used to play Street Fighter IV with this tiny arcade stick on stock controls. At one point I thought "screw it, I just suck at this game."

Then when I was about to toss it out the window thought "fine, I'll build a real stick and give it a shot."

Been playing Street Fighter ever since.


To me enjoyment can only come when the tools fade away from your thoughts.

Also, strategy is one facet of play. Being able to dodge in a pinch and relying on pure timing is also an enjoyable experience. Much harder if lag and playing conditions work against you.

Hey my dude. I'm pretty sure the problem with the lack of slowdown is due to retroarch running the game at the incorrect framerate. Default retroarch, like the one you download from their site, likes to force games to run at 60 fps, even when they are not supposed to. Guwange certainly falls into this category. What version of retroarch are you using? It's funny you're playing Guwange because I am as well. I can help you get the slowdown working correctly.

Genuinely impatient to read an explanation on how you manage to get RA to run such well off-60Hz arcade refreshes rates exactly, on a setup/display that technically can't, without sacrificing smooth scrolling, nor vsync, nor low latency.

I know only of two ways if you don't use a crt/free-gsync/non-edid-locked-lcd setup, one is MAME's refresh slider which I don't know if it's any effective and reliable at all, the other is edid orverrides or emulation, which is a rather hazardous limited solution that when it works gets you close to real rates though not the exact ones, plus it requires an emulator with fixed syncrefresh function such as Groovy.

If neither works but you still get accurate and smooth refreshes, then that means RA features a form of magical variable refresh. Which would be amazing!

I'm on Retroarch v.1.7.3

Good to know, but my findings were from before they had implemented the Run Ahead feature.

To be honest I am not sure how RetroArch is able to run these games at non-60hz frame rates as smoothly as it does. It is interesting and kind of mysterious. I do disable vsync when I play and there are some games, like garegga, that have some screen tearing from time to time. But with DDP, there is no screen tearing at all, or none that I have noticed (and I've played DDP on RA alot at this point).

Here's a quick snippet I just grabbed from my stream. Sorry for the slight pixelation and occasional stuttering, that's my stream not the game.

https://www.twitch.tv/videos/380358625

Use this build instead, Guwange will have correct frame timing and run ahead. Just finished version 3.

https://drive.google.com/open?id=1tgSXvLKaTu1Wh0UYU100fT6O8YoMwYQl

Dude, what the hell? You made a mockery of this whole thread. It worked perfect!

I could tell right away (other than the FPS indicator) that the slowdown and everything is as it should be. The 2nd stage boss was the real test. It was perfect!

What is this "ShmupArch"? Is it a fork with a significantly different implementation underneath? Or just some config tweaks?


Should I use this for all of my games or only for games like Guwange that need "tweaking?"

I guess what I'm asking is does it "just work" or is it something that requires each game with particular refresh rates and so forth to be set manually?

If so, is there a list of already tweaked games?

Again, amazing!


Only thing I thought worth pointing out is that Guwange was pre-set to 4 frames runahead. To my mind it should be set to 3 frames as you don't count the frame that actually renders the input data.

Also, my preferred setting is to vsync but with GPU sync on and set to 3 (I don't know why but it has the least lag even though everyone says it should be set to 0).

I tried adaptive vsync. Not sure if it made a difference but the game plays even smoother (less lag) than ShumpMame for sure even with vsync on.

Very very interested in the future of this "ShmupArch" here. Thanks for the link. I owe you!