Bsnes Hd input delay

Hi, I noticed the new bsnes core has an additional frame of input delay much like the Higan core. Is there any way to get rid of it with settings? Runahead does not work very well with the core so thats no an option. Thanks for any help!

1 Like

Not with settings, no. We really need someone with a high-speed camera and LED-wired controller to determine whether the extra frame exists in the standalone version, as well (it does using standalone’s frame-advance, just as in ours, but byuu wants a real-time verification). If so, I think we can get Brunnis’ stale input fix pushed upstream. If not, we’ll have to maintain a patch for it.

Completely unscientific test of snes9x vs bsnes HD cores running next to each other. Run-ahead disabled. Vulkan with swapchain images set to 1. VSYNC is disabled. This is running on Linux.

Left is snes9x, right is bsnes HD:

http://83.212.109.87/~realnc/vid/snes9x_vs_bsneshd.mp4

Skip to around 0:20 in the video. You should then use a video player that can advance the video on a per-frame basis.

Snes9x is always registering the button press sooner.

1 Like

I checked the Video and I could not notice a Difference.

Though might be a bit of a Difference when actually Playing

You need to play the video frame by frame. Some video players have a hotkey for advancing it by 1 frame. That way you can see bsnes jumping either 1 or 2 frames later.

Or play the video with slow motion (25% speed should suffice.)

He is right unfortunately. Bsnes HD does have one extra frame of input lag compared to the older Bsnes cores and Snes9X. That’s quite the regression for me to stick with the older bsnes, i hope they fix it.

I stick to SNES9X as I think best all around SNES Core

1 Like

I did the same test with stand-alone snes9x and bsnes, and there’s no such issue there. Both emulators have the exact same input latency.

So this problem seems to only affect the bsnes libretro core, not stand-alone bsnes?

I did that same test on win7 and had snes9x and bsnes stand-alones reacting the same on average too.
But snes9x RA is faster vs Bsnes stand-alone.

So maybe snes9x stand-alone is slow for some reason?

byuu said that he will accept the patch:

Someone needs to do a GitHub PR.

Thanks for all of the replies. That patch would be great. Would really love to use this core.

He already added in a patch that should help it, though we’re also looking at ways of dealing with it on our end. Ultimately, I don’t think 16 ms is a big enough deal to not use the core in the meantime, but hopefully we’ll have something for it soon if it’s not already resolved with byuu’s patch.

1 Like

Byuu fixed it. It’s in the buildbot for platforms that can compile it.

1 Like

I asked byuu about savestates not being accurate enough for RunAhead to work correctly on bsnes core:

He stated this is on libretro side problem and will have to be resolved by libretro team.

So I guess there are little chances somebody fixes this on bsnes? It’s a shame we’re tied to snes9x for this. I love bsnes accuracy, but given the advantages runahead gives on latency, it’s not something I want to miss. Playing games like Super Mario World with 3 less frames of latency does make a real difference.

Unfortunately Mesen-S does not support runahead either. Hope @Sour does implement it someday.

there appears to be a misunderstanding somewhere. He’s well aware of the limitations of bsnes states (the lsnes TAS fork of bsnes exists solely for this purpose) and has been actively seeking solutions to the serialization issues for the past few days.

I wouldn’t hold your breath, though. It’s a complex, possibly unsolvable issue issue in this case, and I don’t think they’ve made any progress with it so far.

Either way, it seems to be a touchy subject, I guess, so probably best not to bring it up with him.

There was a single missing variable in the save states up until yesterday that was corrupting some states and causing issues with rewind, but beyond that runahead should be supported, afaik.

The patch worked great but the last few core updates have caused the core to not launch. Had to revert back to the first version of the core with the input delay patch implemented.