Input Lag Compensation to compensate for game's internal lag?

RetroArch General
#225

Turns out that I was doing things in a different order than Retroarch does things.

RetroArch’s Order:

  • Init Symbols
  • Init Environment Callback
  • Init Core
  • Load Content
  • Init Callbacks (video, sound, input, etc)

My order:

  • Init Symbols
  • Init Callbacks (video, sound, input, etc) <- mesen crashed here
  • Init Environment Callback
  • Init Core
  • Load Content

The crash happened during while initializing the Audio callback. Changing the order to match Retroarch stopped the crash. Strange how only Mesen seems to care about what order these steps happen in.

edit: Note that Mesen is probably too slow to use with runahead, it would need more optimizations first.

3 Likes
#226

Mednafen PSX HW does not work either : I get sound, but no picture.

Edit : and another one ! PPSSPP does not work, it crashes RA.

#229

I was wondering if someone could build a Wii version of RetroArch with runahead enabled using the Snes9x 2010, core I just want to see if Runahead works at a playable speed on that platform.

#230

I could enable HAVE_RUNAHEAD for the Wii version, the problem is that the Wii (and WiiU, and every other console) does not have HAVE_DYLIB or HAVE_DYNAMIC defined.

Will this prevent runahead from working altogether?

1 Like
#231

Runahead just needs savestates, no other requirements. You end up with runahead without using a secondary core, which requires good audio support from the core after loading state.

I ended up building a Wii version (fixed some compiler errors along the way, will push that), and now I can’t test it because my Wii just happens to be broken right now. It won’t boot the system menu, won’t boot the Homebrew Channel, it’s just stuck at Bootmii.

Edit: Somehow the wii just started working again… It ran Super Mario World at 38FPS when using runahead of 1.

#232

With which core was this? Snes9x 2002/2005 should be significantly faster than 2010 even. But not sure if we have Wii targets for those yet, but it shouldn’t really be difficult to do them in case they are missing right now.

The WiiU and PS3 have a bit more horsepower, maybe runahead would be nice there.

1 Like
#233

@Dwedit hey, I’m responsible for the Retro Achievements integration in RetroArch.

Someone just made me aware of a possible issue with the runahead feature and achievements. So, quick question: do the runahead frames cause cheevos_test to be called? If not, we’re good.

Otherwise, imagine that the player gets an achievement in a runahead frame. But because the input state has changed, the frame is discarded, and in the new path the achievement is not really completed. Since it was already tested for, the player has already earned the achievement, and that action cannot be undone like the frame is.

The solution is to only call cheevos_test after frames that really contribute to the game and that are not discarded. If that means there will be a couple of frames of lag for achievements to trigger, it’s fine, achievements don’t have hard requirements regarding latency.

1 Like
#234

Cheevos_test is called after the core_run replacement code, so it can’t be called during runahead time. Also, the core_run replacement code never puts the primary core in a different state than simply running one frame.

1 Like
#235

I’m not sure I follow. The issue is not testing for achievements ahead of time, but testing after a frame that is later discarded. If that’s what you mean, than we’re good.

#236

After calling “run_ahead”, it is never left in a future state once “run_ahead” completes, it just leaves it at the next frame, as if you had called “core_run” instead.

#237

Awesome, thanks for the clarification.

#238

HAVE_RUNAHEAD should now be defined for the PS3, Wii and WiiU builds.

1 Like
#239

Yeah, I’ve noted that too. Maybe the limit should be based on the genre of the game, for instance, megaman, being a platformer, its more importarnt to reduce lag on the jumps, becose its what will make you fall to your dead if you jump too close to the edge and the game dont react fast enough, in Mario games too. just my opinion.

2 Likes
#240

Found a minor issue in Super Mario World. While most actions are lagged by two frames, pausing the game is only lagged by one frame. So with two frame runahead, the screen will snap back a pixel or so if you pause while moving. I’d still consider two frames to be the correct lag compensation though.

1 Like
#241

Funnily, these past weeks I have been doing tests for UMK3 arcade vs various emulators and setups, using 60fps video.

Here is the input delay/lag results

And also, if anyone cares, here are the results of speed differences:

#242

The Xbox 360 version hasn’t been updated in years yeah. That is a very old version. Hopefully I can get it resurrected at some point in time (already did the Xbox OG port). Would be nice to compare it to PC RA too.

#243

May I just briefly report my own experience in MAME, in particular MAME 2010: With very snappy old school games, such as 1942, Gyruss or Pacman, this is indeed a game changer. Runahead of one instance of 2 frames, for the first time, brings me into real Arcade territory as it used to be in the old days. In particular 1942 is the best testing environment for this. Tested on my Mac under MacOS and Linux, apparently OpenGL. Shaders and Overlays play nicely. I am in Arcade heaven - finally :slight_smile: . Will continue testing, but until now already flawless.

3 Likes
#244

@Dwedit, do you think anything can be done about making Secondary Instance work with Beetle PSX without the stuttering it exhibits right now?

At the moment I am experiencing stutter anytime I press any input with the Secondary Instance option enabled, regardless of the amount of Run-ahead frames specified.

#245

Core is outputting multiple frames through hardware acceleration, so it renders two frames instead of one, waits for vblank twice, thus runs at 30FPS.

The systems for disabling frame output were designed for the cores which render to a frame buffer and call the video output callback, which gets disabled when frames should be discarded. There is no method right now of discarding frames when using hardware acceleration.

I currently don’t know the details of how hardware accelerated cores work. If the cores get an actual OpenGL driver, and call SwapBuffers, then there is no way for the frontend to stop that automatically.

The frontend does have a flag it can set to tell cores not render a frame, but the core needs to be modified to respect that flag.

#246

Just to be sure, what you’re describing is also applicable when only using the software renderer within Beetle PSX, right?