Strange feeling while using run ahead

[Costra]

Hello. I have an arcade 15khz pc (i7 8700) where i play mame, fightcade and retroarch (shmuparch). I also have a mister fpga.
When i set up run ahead in fightcade or in retroarch, the lag is obiously reduced but it feels awkward in a lot of games. It is like there are micro speed changes while playing the game and the game is not responding to inputs in the exact way all the time. That is why i still play on groovymame in most games even though the lag is slightly higher than in fightcade/shmuparch using run ahead. In mister everything feels perfect in a lot of games though, the problem is of course the amount of shmups you can play there is not huge.

There are some games where run ahead feels good too, like in most fighting games of fightcade, so im not sure if it is something of the settings that im missing. I also tried to search info about this topic on the internet and there is not too much... I cannot be the only obe experiencing this, right?

[Starfighter]

Sometimes using runahead I have to really make sure the game is caught up, for example going up ladders in platformers. When I'm up and start walking right I sometimes glitch back down the ladder and get stuck. The only thing to do is keep pressing up on the ladder an extra frame or two to make sure I'm really up before I go sideways. Is this something that's related to what you're experiencing? If it is, I solved that by reducing the number of frames used in runahead in those particular games.

[Bassa-Bassa]

A game originally doesn't necessarily have the same input lag throughout (I think it's rare the case it does?), so that may be a factor. Runahead is a hacky feature by nature, one should never forget that.

[Steven]

Is that why in PS4/Switch Hishouzame I can sometimes press the shot button to fire a single shot and release it super quickly and I see the shot begin but then disappear instead of working properly?

[blazinglazers69]

How many frames are you running ahead? 2 with early polling works well for many arcade games I play. SNES games tend to be 2-3 and Genesis tends to be 1-2.

[-Fish-]

How many frames are you running ahead? 2 with early polling works well for many arcade games I play. SNES games tend to be 2-3 and Genesis tends to be 1-2.

This ^

It's going to be different for every game. For many Raizing shmups I'm using 4. Cave shmups though generally 2. If you go too far you will recognize it with odd gitters in the gameplay.

[Bassa-Bassa]

Is that why in PS4/Switch Hishouzame I can sometimes press the shot button to fire a single shot and release it super quickly and I see the shot begin but then disappear instead of working properly?

I don't think so. Has M2 unveiled that they use runahead in their emulations? Not that it would surprise me much, they for sure must have some techniques any other developer lacks. Anyway, is that a glitch which doesn't happen with the original PCB?

[StrzxgvNuvWvfld]

I have a different problem where the player sprite will often move back slightly when I stop holding a direction on the controller. This is only with 2 frames of runahead. It seems to occur with lots of different games. I've recorded the screen in slow motion to confirm I'm not imaginig it!

[Lander]

Rule Number Two of using run-ahead:
If you're guessing or using a general number instead of manually measuring and dialing in the run-ahead frames setting for each game, you're doing it wrong.

1. Boot up the game and get to the point where you have control of your character
2. Wait until any on-spawn invincibility flashing stops so your character is visible frame-to-frame
3. Press K (or whatever you have frame advance rebound to)
4. Press and hold an input that you know will cause immediate visual feedback in-game (i.e. move, fire, jump, all of the above)
5. Counting the number of presses, press K until the visual feedback occurs
6. Set run-ahead frames to the number of times you pressed K minus one
(1 press = 0 frames, 2 presses = 1 frame, 3 presses = 2 frames, and so on)
7. Open the quick menu, navigate to the Overrides section and select Save Game Override

Voila, you now have a proven-correct, per-game, persistent, runahead setting.

A game originally doesn't necessarily have the same input lag throughout (I think it's rare the case it does?), so that may be a factor. Runahead is a hacky feature by nature, one should never forget that.

In my experience, inconsistent lag (insofar as it affects properly-configured runahead) has been the exception rather than the rule across 100-or-so games from the 8/16/32-bit console and arcade era.

Off the top of my head, the only game with noticeable artifacting has been DoDonPachi; in moment-to-moment gameplay it has 1 frame of internal lag, but certain intense moments (notably the enemy that fires two large spiral orbs that split into a radial shotgun of many smaller spiral orbs) cause bullets to rewind all over the place if any of your inputs change before the underlying machinery has had chance to recover.

Though MSX seems to be an outlier - everything I've tried (Zanac and the Aleste series, primarily) exhibits wildly variable internal lag, to the point where any run-ahead at all will exhibit rewind artifacting.

I have a different problem where the player sprite will often move back slightly when I stop holding a direction on the controller. This is only with 2 frames of runahead. It seems to occur with lots of different games. I've recorded the screen in slow motion to confirm I'm not imaginig it!

This is definitely due to having too many frames of run-ahead. The character will be jumping ahead by 1-2 frames when you press the move input, then jumping back by the same amount on release. Dialing it in as per the above should fix it.

Is that why in PS4/Switch Hishouzame I can sometimes press the shot button to fire a single shot and release it super quickly and I see the shot begin but then disappear instead of working properly?

That certainly sounds like runahead artifacting - actions effectively being rewritten if you input them quick enough for the press-release window to intersect the runahead window - but I dunno nuffin about the console side of things.

[Steven]

Is that why in PS4/Switch Hishouzame I can sometimes press the shot button to fire a single shot and release it super quickly and I see the shot begin but then disappear instead of working properly?

I don't think so. Has M2 unveiled that they use runahead in their emulations? Not that it would surprise me much, they for sure must have some techniques any other developer lacks. Anyway, is that a glitch which doesn't happen with the original PCB?

I don't know. trap15 once suggested that M2 might be using runahead, but only M2 knows. I did notice this also happens in Kyuukyoku Tiger, as well, and it happened today, so I recorded it. Here it is: https://youtu.be/lXJ6UlvRDnM

I'm not using autofire here, so it's definitely not related to that.

[Rastan78]

Just speculation here. It could also relate to correcting game speed to match arcade refresh while on consoles and monitors that are locked to 60hz. Given the noticable stutter on M2 K Tiger I would guess the PCB runs at some significantly slower speed around 55hz? The stutter is not a bad thing, just a needed tradeoff outside of speeding the game up to 60hz (will scrool smoothly but feel different to the PCB) or porting to PC/ new gen consoles and enabling VRR.

So certain frames must be doubled and kept on screen longer. Maybe you hit the button and released very quickly on a frame that is doubled and the input was not active on that second duplicate frame? Just a guess.

I have noticed that on many autofire speeds in M2 ports the input is held for 2 frames consecutively before being released.

[Sumez]

TLDR; a run-ahead feature should never attempt to mitigate any more lag frames than what are inherent to to the game's logic

[Steven]

Given the noticable stutter on M2 K Tiger I would guess the PCB runs at some significantly slower speed around 55hz?

I want to say it's 54.7 or something like that. It runs on the same hardware as Hishouzame, and I think that's Hishouzame's refresh rate, so I would be very surprised if it was different.

[pulsemod]

M2's ShotTriggers releases have a latency reduction option (on by default) in the extra settings. if this doesn't ever happen when that option is turned off, maybe that'll determine whether it's run-ahead?

[Lethe]

You can witness DDP's variable lag by overclocking the machine cycles (it increases to a consistent 3f). Raizing Bat* games have variable lag as well, don't know about the Mahou games.

Is there any way that M2 could implement toggleable lag reduction that isn't runahead, assuming they're emulating accurately? I don't know how that option would function without it or something similar. The funny part is, if that is the case then M2 could have created lagless ports but chose not to. A bit of a castigation to those abusing runahead to its extremes, yes?

[StrzxgvNuvWvfld]

Is there any way that M2 could implement toggleable lag reduction that isn't runahead, assuming they're emulating accurately? I don't know how that option would function without it or something similar. The funny part is, if that is the case then M2 could have created lagless ports but chose not to. A bit of a castigation to those abusing runahead to its extremes, yes?

If the PCB has lag (eg Garegga) I'm guessing you could disassemble the code and re-write the input routines (which could then be patched in/out). They do talk about disassembly on the MLiG interview. I would guess run-ahead would only be used to reduce lag caused by the emulator.

[Lethe]

If the PCB has lag (eg Garegga) I'm guessing you could disassemble the code and re-write the input routines (which could then be patched in/out).

Maybe they could, but IMO that's pushing the boundaries of "emulating accurately" (and counter to M2's goals). It's a romhack. But M2 obviously aren't averse to having configurable patches either, so it's ultimately a matter of what they think is the less invasive option. My logic is, it's not like the principles of runahead are new: rollback netcode has existed since ~2007 and is pretty similar; it's believable someone else adopted the concept. It would also match up with M2's complaints about performance requirements. And if they were willing to actively rewrite the ROMs for optimization's sake, why not take it a step further and do a ground-up port instead?

I would guess run-ahead would only be used to reduce lag caused by the emulator.

As this thread evidences, runahead will only affect the game's internal lag. You might mean using runahead to counterbalance added lag from emulation/hardware in lieu of an alternative, which is what I'm assuming the latency reduction option exists for. The emulation lag by itself should be small anyway, modern MAME's overhead on well-emulated systems is a fraction of a frame and I can't imagine M2's environment being worse.

[Lander]

Just speculation here. It could also relate to correcting game speed to match arcade refresh while on consoles and monitors that are locked to 60hz. Given the noticable stutter on M2 K Tiger I would guess the PCB runs at some significantly slower speed around 55hz? The stutter is not a bad thing, just a needed tradeoff outside of speeding the game up to 60hz (will scrool smoothly but feel different to the PCB) or porting to PC/ new gen consoles and enabling VRR.

So certain frames must be doubled and kept on screen longer. Maybe you hit the button and released very quickly on a frame that is doubled and the input was not active on that second duplicate frame? Just a guess.

I have noticed that on many autofire speeds in M2 ports the input is held for 2 frames consecutively before being released.

It being down to frame duplication seems implausible, since duplicate frames are a result of the emulation not having ticked over to the next frame by the time the display does. That makes them immutable without some mechanism to force the underlying machine to tick out of step and replace the current frame with a new up-to-date one in time for the display refresh.

But, you could well be onto something with the refresh rate mismatch. It's all very implementation-dependent, but if it's using runahead without accounting for whatever 1-1-1-1-2-1-etc tick pattern the game exhibits, an input changing state during the 2 period could cause unexpected behaviour and ultimately breach some underlying assumption about the state of the machine. Though this is also just speculation

I don't know. trap15 once suggested that M2 might be using runahead, but only M2 knows. I did notice this also happens in Kyuukyoku Tiger, as well, and it happened today, so I recorded it. Here it is: https://youtu.be/lXJ6UlvRDnM

I'm not using autofire here, so it's definitely not related to that.

That certainly looks like an over-runahead, particularly the way the copter's movement also appears to jump back by a couple of pixels when the bullet disappears.

What strikes me as interesting is that the control information widget doesn't show the fire button being pressed for that last shot - only the quick quarter circle movement you did at the same time. That aligns with general runahead wisdom, since it's often the falling edge of a released direction or button that catches the runahead period in time to cause a visible rewind.

Anecdotally, it also suggests that M2 are using the emulator's input memory to drive the UI rather than hooking it directly into the host platform's input API, which makes sense given their penchant for accuracy.

All that said however, I booted KT up in retroarch and wasn't able to reproduce the disappearing shot despite a good amount of flailing and quick tapping. The game has 1 frame of internal lag by my measure, but dialing runahead up beyond that didn't reveal any new behaviour aside from some obvious and expected movement rewinding. Though that could also be down to internal lag inconsistency and/or me being a scrub when it comes to frame-perfect inputs

In summation:

If the PCB has lag (eg Garegga) I'm guessing you could disassemble the code and re-write the input routines (which could then be patched in/out). They do talk about disassembly on the MLiG interview. I would guess run-ahead would only be used to reduce lag caused by the emulator.

It's certainly possible in theory, though there are all sorts of factors that occur alongside input code that could contribute to an internal bottleneck and ultimately manifest as internal lag frames. Beyond a certain point you'd probably end up looking at full-on reverse-engineering if the emulated system plus enhancements isn't able to maintain the required degree of consistency.

[StrzxgvNuvWvfld]

It's certainly possible in theory, though there are all sorts of factors that occur alongside input code that could contribute to an internal bottleneck and ultimately manifest as internal lag frames. Beyond a certain point you'd probably end up looking at full-on reverse-engineering if the emulated system plus enhancements isn't able to maintain the required degree of consistency.

Maybe they could, but IMO that's pushing the boundaries of "emulating accurately" (and counter to M2's goals). It's a romhack. But M2 obviously aren't averse to having configurable patches either, so it's ultimately a matter of what they think is the less invasive option. My logic is, it's not like the principles of runahead are new: rollback netcode has existed since ~2007 and is pretty similar; it's believable someone else adopted the concept. It would also match up with M2's complaints about performance requirements. And if they were willing to actively rewrite the ROMs for optimization's sake, why not take it a step further and do a ground-up port instead?

It isn't entirely about accuracy though, they allow you to change bullet colours, they add easy modes and arrange modes etc. The latency reduction is just another thing you can toggle on/off. I think some of the games (certainly Garegga) have a version number which would again suggest to me they've rebuilt the rom. If you're going to create a whole new arrange mode, it would make sense to me (with very limited exeperience of this kind of thing!) to create some kind of source code you can work from and change. We know that sometimes they also do full ports, Eg Futari on the 360 (which I believe is well respected) or Virtua Racing on the Switch. That's not to say for one minute they aren't using run-ahead, I'm just theorising what techniques they could be using. I'd love it if they did a breakdown of their processes with each release to answer some of these questions.

As this thread evidences, runahead will only affect the game's internal lag. You might mean using runahead to counterbalance added lag from emulation/hardware in lieu of an alternative, which is what I'm assuming the latency reduction option exists for. The emulation lag by itself should be small anyway, modern MAME's overhead on well-emulated systems is a fraction of a frame and I can't imagine M2's environment being worse.

This is interesting. I've never really thought about how run-ahead works before (I don't really play games on my PC very much), but are you saying if a game has 1 frame of latency and an emulator has 3 frames, you'll never reduce the latency by more than that one 1 frame? That would certainly explain some of the glitches I've seen in Retroarch. I think the feeling online is that you can pretty much wipe-out emulator related latency with run-ahead, when as you say what you're doing is removing game lag to counter-balance lag added by emulation.

[pulsemod]

lag added by a good emulator itself might as well be negligible, latency isn't inherent to emulation. I'd recommend trying to reduce latency via the rest of the configuration before resorting to tricks like run-ahead, there's a good chance that some of those extra frames can be shaved off

[Steven]

That certainly looks like an over-runahead, particularly the way the copter's movement also appears to jump back by a couple of pixels when the bullet disappears.

Pretty sure that's just me moving the stick back, as it does seem to align with the input display on the HUD, but...

What strikes me as interesting is that the control information widget doesn't show the fire button being pressed for that last shot - only the quick quarter circle movement you did at the same time. That aligns with general runahead wisdom, since it's often the falling edge of a released direction or button that catches the runahead period in time to cause a visible rewind.

It could also be because the PS4's internal capture thingy only captures at 30FPS, so it's possible that the input timing coincides with the skipped frame or something.

All that said however, I booted KT up in retroarch and wasn't able to reproduce the disappearing shot despite a good amount of flailing and quick tapping. The game has 1 frame of internal lag by my measure, but dialing runahead up beyond that didn't reveal any new behaviour aside from some obvious and expected movement rewinding. Though that could also be down to internal lag inconsistency and/or me being a scrub when it comes to frame-perfect inputs

You mean that you press the button and then the action happens on the next frame? That is extremely fast, and I cannot think of many games that do that, as it is quite rare, but not completely unheard of, as I have heard before that games with such speeds do exist. If so, those Toaplan dudes did a hell of an outstanding job getting that fast of a response time. I'd be interested in testing it on Hishouzame, which runs on the same PCB, and also some of the other Toaplan boards, as well, like Slap Fight, just to see how they compare. Same with M2 Garegga, for that matter, on both PS4 and Xbox.

[Bassa-Bassa]

As I understand, 1 frame of lag, is not next frame response, but indeed 1 additional frame over it.

[Steven]

That's what I'm thinking it should be as well, but might as well ask.

[Lethe]

Typically when someone says "2 lag frames" they mean a response 2 frames later. That includes KT, Sames etc. The reason for this is that if you take a game with instant response (e.g. Omega Fighter, Gun.Smoke), you're still waiting for 1 frame for the game to refresh after an input, so it's 1 lag frame, not 0. And going below 1 frame response isn't possible barring some really unconventional approaches like decoupling the input from the refresh rate. Part of the problem is that most shmups run at a fixed 60fps or lower, so even if your processing lag is nonexistent, you're stuck waiting for the display update.

1~2 frame latency is far from some rare genius BTW. Even amateur PC games make arcades look like they've got low standards. A (vpatched) Touhou game is more responsive than its contemporary arcade games, and even well-made Game Maker games get 2 frames.

[Sumez]

Frames of lag are generally counted from the moment a button is pressed until you can see any reaction on your character. So even if the hardware is completely lag-free, game logic dictates that you'll always have at least around a frame of perceived lag. Measuring lag outside of video game lagic, even a device like the time sleuth will consider a completely lag-free CRT as having "8ms" of lag at 60hz because of the ~16ms it takes to draw a frame.

Arcade games from earlier than the mid 90s have very very few excuses to have more than 2 frames of lag honestly. They definitely exist, but I consider it kinda baffling that they do.

[Lander]

You mean that you press the button and then the action happens on the next frame? That is extremely fast, and I cannot think of many games that do that, as it is quite rare, but not completely unheard of, as I have heard before that games with such speeds do exist. If so, those Toaplan dudes did a hell of an outstanding job getting that fast of a response time. I'd be interested in testing it on Hishouzame, which runs on the same PCB, and also some of the other Toaplan boards, as well, like Slap Fight, just to see how they compare. Same with M2 Garegga, for that matter, on both PS4 and Xbox.

Nah - without runahead, I press the button, nothing happens on the next frame, and then the action happens on the frame after that. So setting 1 frame of runahead cuts out the delay and makes the action occur on the frame after the input.

And yeah, zero internal lag is a rare and pleasant surprise - the only arcade games I've encountered with that are Gradius and Slap Fight / Alcon. I figured having at least 1 frame was non-negotiable until stumbling across those, so hats off to the devs for building some seriously lean loops.

And for what it's worth, it looks like Hishouzame is a 1-frame game like Kyu Tiger, so I'd expect similar behaviour under the same conditions.

[Steven]

I knew there was a reason that I love Slap Fight so much. The programmers of that game were Yuge and Wada... interesting.

I played Slap Fight for a while on MAME, or at least I tried to play it on MAME, but the input lag was somewhat annoying, so I gave up and bought the PCB and immediately noticed a massive improvement, which is interesting given that I seem to be extremely insensitive to input lag unless it's really REALLY bad. It does make me wonder how much lag M2's Slap Fight will have when they eventually get around to releasing it.