1 or 2 frames of input lag in emulated SMW?

I found the tip in several places to use RetroArch's Run Ahead option to get rid of input lag. I got the tip to run 2 frames ahead. But after testing the input lag myself I am not so sure anymore.

Look at this:
https://imgur.com/a/LlHvdm6

Images recorded in Kaizo Kindergarten, because it has the input display at the top. On RetroArch with the 'bsnes mercury performance' core.

What I want to know is if a real SNES also shows the B input 1 frame before Mario actually starts his jump. In other words, does hardware SMW have 1 frame delay for Mario's movement?

PS. results are the same for simply moving left and right. the input shows 1 frame before Mario moves.

I use run-ahead of 2, simply because it feels the best for me to play and I don't notice any chopped animations at that setting yet.

I haven't tested this on real hardware (haven't hooked up my SNES), but internal lag is definitely a thing that exists with games. Games can do all kinds of processing on input, which can absolutely lead to a couple of frames of delay between input and a reaction. This is more common for modern 3D games, though. Since the hack probably just uses the game's RAM to render the overlay, what it shows you is very likely what a real SNES would also do.

So based on your screenshots, and based on my own experiences, run-ahead of 2 frames definitely seems ideal for SMW, since it was skip frame 0 and frame 1 of your example.

---

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Thanks for the reply.



You misunderstood. Frame 0 has no input yet. It is just paused there. The first time the game can possible see the B button is frame 1. So based on the response in frame 2, it would be correct to play with 1 frame runahead.

This means that you are probably playing a more responsive mario than a snes would.

Do you see? Or did I misunderstand you?

Yes, I get what you mean. I thought your frame 0 was when you pressed the jump button on your PC.

By that logic, you'd be right with using one frame of run-ahead. However, as I said, it's possible that the hack just uses SMW's input RAM address to display the button overlay, and it's possible that this RAM address itself already has a frame of delay in it. Therefore, two frames of run-ahead might still be "correct". I don't think using the in-game overlay is an accurate measure for testing this. A more accurate measure would probably be to take videos of Mario jumping with every possible run-ahead setting. Once frames of Mario's movement/animation start getting skipped, you'll know that the setting is too high.

Also another thing to note is that run-ahead only skips the game's internal input lag in the first place, so no matter what run-ahead setting you use, you'll always have a game that is "more responsive" than original SMW. However, modern hardware usually adds a bit of input lag here and there, and emulators also have their own input lag along the way, so getting rid of the game's internal lag can help offset that lag and get to something that feels like the original SMW on a CRT. Still, ultimately, any run-ahead setting above 0 is technically "more responsive" than original SMW.

---

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Maybe I can try tomorrow with my snes and smw to see how it is on the real thing. Hope my phone has a good enough slomo setting on the camera.