MAMEWorld Forums - EmuChat

> I've never seen anyone figure out all the best settings to reduce it meaningfully. If
> you figure it out let us know but I don't think anyone here has figured it out, thus
> you not getting an answer.

Well, as I said: It's not about reducing input lag from an absolute point of view. If someone thinks that the games already lag with the default settings, then I can't help him either. What I was referring to: If we take MAME with its default options as the basis, how will other options increase input lag?

An example: If you say that
mame suprmrio
plays fine for you, input-wise, but you want to remove the tearing when the game scrolls, then you might ask yourself what options to set without adding input lag. And that's what my tests were about.

My results:

If you have your screen set to 60 Hz and play "Vs. Super Mario Bros." (which is also set to 60 Hz) and Mario stands on the ground and you press the jump button, then it will take 3 frames until he jumps. So, from pressing the button to the first jumping animation on the screen it's 3 frames. That's our basis. And now we see how many frames the whole procedure needs with additional options.

At first: Don't use triple buffering. Triple buffering is deadly. Using triple buffering adds 2 to ~3.5 frames to the general 3 frames before the output reflects the input.
As I said above (and if I've understood triple buffering correctly), that's natural: If you render two screens in memory before displaying them, the visible output is always two frames behind the actual game scene. Even the most perfect hardware cannot do anything against it: If MAME shows scene 1 while rendering scene 2 and 3 in memory, then the input will refer to scene 3 while you are seeing scene 1 on the screen. That's why you shouldn't use triple buffering. Input lag is an integrated part of it and my tests confirmed it.

The other option to remove tearing: vsync. Here, it is a bit strange:
If you use Direct3D, vsync will produce about ~3.3 additional frames. (So, since the duration without any options is 3 frames, with vsync in Direct3D, Mario will take ~6.3 frames until he jumps.)
But if you use vsync with DirectDraw, then the lag will merely be ~0.3 frames, i.e. less than a single frame on average.

I don't know why that's the case. I don't know why vsync in Direct3D lags so much more than vsync in DirectDraw. My PC is from 2010, an Intel QuadCore, 2.33 GHz, 4 GB RAM, which should be more than enough to run MAME smoothly, so it's probably not the hardware. I even checked the stuff with MAME 0.127 from 2008. It must be a Direct3D issue. I also noticed input lag in the NES emulator Nestopia when vsync is enabled while there doesn't seem to be any noticable input lag in FCE Ultra. And guess what: FCE Ultra is DirectDraw, Nestopia is Direct3D.

Conclusion: If you want to play a game without tearing when the game scrolls and without relevant input lag, the best option is
mame -video ddraw -waitvsync -notriplebuffer
Triple buffer always lags. And Direct3D lags if you combine it with vsync. Vsync with DirectDraw is almost as good as with standard options.

How did I measure it? Quite easy. Everybody can do this and check the results for himself: You need a video camera that can shoot videos with 60 FPS. Set your monitor to 60 Hz. Start MAME with "Vs. Super Mario Bros." (or any other game you want to check) and map the jump button (or whatever button you need) to either the Num Lock, Caps Lock or Scroll Lock key. Those are the keys that are connected to a small LED on the keyboard. Now position the video camera in a way that the keyboard LEDs and Mario on the screen are in good view. Record it and let Mario jump a few times. And now watch the video frame by frame. As soon as the LED starts glowing, count the frames to see how long it takes from the keyboard physically registering the key press to the first jump animation. That's it.

About the relationship between MAME and an actual arcade board: Well, you would need an input device with an LED and could do the same. I don't know if "Super Mario Bros." on an actual arcade board or on an NES would need three frames from button press to output or if it reacts even quicker. But that's something that someone who owns this stuff and who knows how to connect an LED to a controller could find out quite easily. That's why I don't really understand how there can be so much controversy about it. Get a camera, put it to 60 FPS and then record the screen and your input device LED. Do this 20 times and you should have quite a reliable average value which you could check against MAME. Then you know if the complainers are right or if they just imagine an input lag.
This guy did it with the PlayStation "Street Fighter" games and he's the one where I got the method from:
www.youtube.com/watch?v=JoJzobmdGzU