The only issue with run-ahead is that contrary to frame_delay and frame slice (beam racing) methods it allows users to abuse lag reduction and break beyond the compositing frame which emulators use to tie the graphics data together and which you can (and should) vsync without adding other unnecessary 2~3 flip queue frames (like for instance classic d3d9 or bgfx do) by turning frame_delay on, or simply use the d3d9ex backend, or even ddraw on older MAME versions and get only 1.
Adjusting frame_delay or frame slice settings then allows to register the input data within the same time as that compositing frame, effectively challenging the last bits of unnatural input lag, the higher the setting the closer to the game's time proper
(iirc a frame_delay setting of 9 = 16.67ms so the whole frame can be defeated but it's extremely heavy, 7 or 8 are much more accessible. Frame slice if it could work with most games would be less cpu/gpu intensive, too bad it's till a pipe dream)
If you have a lagless display then (like 0~3ms top bar on the LB test) depending on your settings and PC's processing power (you can also make sure your controller pcb doesn't add delay and oc a dedicated usb port to 1K polling rate) you can then play with only mere miliseconds of input lag left, well under under 1 frame, just before the game's legit time.
The latter, the emulated game's lag, is natural and expected if the driver is accurate, with many games producing the equivalent of two frames, some three etc, it can even vary a bit during play depending of the graphics load, and indeed we shouldn't seek to defeat that assuming playing with the most accurate settings we can for fairness is the objective.
I see no problem with killing as much lag as possible using run-ahead for personal enjoyment, but if people don't mention doing that while recording videos or streaming, then yeah there's an issue with fairness and it could be considered cheating.
All methods for reducing lag are valid except when they break accurate emulation, shmupmame's removal of several drivers internal buffers, many of those necessary for accurate emulation, is bad and banned. As well as pushing run-ahead too far is. And finally it's not as bad only stupid: turning all forms of vsync off and playing with tearing, only idiots still haven't got that they don't need to do that to play closest to the game's time (or they do but their pc is so weak that it's the only method they can afford, they'e the only ones with a good excuse, but again plain ddraw or d3d9ex add only 1 which is bearable for many games)
Now about some misconceptions:
- no, PC's don't necessarily lag any significantly more than pcbs when shit's done properly, there were issues but so far fixed with XP, 7, 8 and lately Linux (dunno for 10 I don't use it for gaming) nobody would have cared researching lag reduction methods if computers always added like 1 or 2 undefeatable frames.
- GroovyMAME savestates crashes; a fix has been there since v0.200, nobody cared to check or try it seems.
- GroovyMAME is only for CRT's/15KHz and only works with old AMD GPU's; no, not only it can provide the same benefits with LCDs (100% refresh accuracy on everything and lag reduction) and of course assuming your own flat panel is flexible enough to accept many if not every modes (mine does from 50 to 75Hz and it's a basic full-hd not even freesync, it's worth trying) but it's been expanded to work with 4K and the upcoming version of CRT_Emudriver will support up to Vega.
There's also a simplified 'lazy' method that allows to use your own custom resolutions created from your control gpu's panel or CRU, it works even without CRT_Emudrivers and even with nVidia cards, but since it uses fixed resolutions and common AMD/nVidia utilities aren't very flexible it is of course less accurate, still allowing less than 1% deviation though.
The guide for advanced Groovy on LCDs was published on eiusdemmodi http://geedorah.com/eiusdemmodi/forum/v ... php?id=374 while it sure is more complicated than flipping buttons in an emulator's UI, well, it works too.
There would be much more to say about how MAME works and the specificities of certain drivers and games, some do lag more for reasons, sometimes plainly because that's how they are on the real hardware as cools say, sometimes maybe because a MAME driver isn't optimal and an unwanted frame can safely be removed with a hack (no problem with that if it's indeed unnecessary and therefore not breaking anything), sometimes because MAME needs to emulate things separately like with some 3D games, or emulating hard drives etc. in which cases many tasks can bloat single CPU threads and maybe affect response, so multi-core CPUs will have an advantage, etc etc
--
Yup, well, I ended up wasting bytes posting on shmups forums again lol. gotta fuel the hate over 4shit and the discord sheepyards once in a while I guess.
