Input lag
Input lag
We have interesting talk in IRC right now, but i don't have time to read all it now.
So i decide to make a thread about it.
Some mame versions have moar input lag than another.
Is if i wanna play Cave/Psykio/Raizing games in mame, which version are better fro specific games?
Also, maybe the mame isn't the best choice?
So i decide to make a thread about it.
Some mame versions have moar input lag than another.
Is if i wanna play Cave/Psykio/Raizing games in mame, which version are better fro specific games?
Also, maybe the mame isn't the best choice?
Re: Input lag
Just wanted to clarify the reason as to why this happens on the P3. Is it only a problem on non-CRT TVs? Is it a problem with the emulator(s)? Is it caused by the wireless pad? Or is it a combination of all these things?
Re:
So it adds lag but the standart method of detecting lag (pause and frame by frame advance) cannot detect it?nimitz wrote:both work,
you can disable vsync AND triple buffering in mame.
or
force vsync AND triple buffering OFF with your video card driver.
that being said vsync and triple buffering add delay for EVERYTHING, so might as well force them off
Is there another way of testing if and how much v-sync adds frames of input lag. It would be nice to know for a fact.
"In short, it comes down to spirit" - dodonpachi developper Kohyama.
Re: Input lag
I would say that 1 more frame of input lag is a far cry from making a game unplayablenimitz wrote:But id MUCH rather have a bit of tearing than input delay that makes the games unplayable.
Re: Re:
Record video with a 60FPS camera and have the relevant input switch wired up so that it turns an LED on. Then frame-advance the video and see how many frames go by between the LED turning on and the sprite reacting on-screen. Bonus points if you manage to wire up the same switch to also control a PCB running alongside the emulator.The vagrant wrote:Is there another way of testing if and how much v-sync adds frames of input lag. It would be nice to know for a fact.
Re: Input lag
It's not a far cry, but it doesn't make a game unplayable.ncp wrote:I would say that 1 more frame of input lag is a far cry from making a game unplayablenimitz wrote:But id MUCH rather have a bit of tearing than input delay that makes the games unplayable.
Still, given the choice, I'd easily take tearing over control lag. I'd rather know that my reflexes/planning/whatever weren't enough, rather than my reflexes/planning/whatever + anticipation because of input lag weren't enough.
Re: Re:
You can only determine input lag that way, not output lag. For example, most LCD monitors also add lag due to image processing, but you wouldn't be able to detect it by frame advancing in MAME.The vagrant wrote:So it adds lag but the standart method of detecting lag (pause and frame by frame advance) cannot detect it?
Implemented in a perfectly ideal fashion, double-buffered vsync would add between 0 and 16.67ms of lag (0-1 frames) to a game designed to run at an even 60fps displayed on a monitor set for 60Hz refresh rate.The vagrant wrote:Is there another way of testing if and how much v-sync adds frames of input lag. It would be nice to know for a fact.

Re: Input lag
Okay I tested some more, by launching the same games on both mame+ extended and shmupmame 2.2, with vsync and triplebuffer on and off.
It appears the games were slightly more laggy with vsync, and triplebuffer doesn't affect anything. I tested vsync and triplebuffer standalone.
Very heavy emphasis on "appears". I do not trust my senses to be able to tell 1 frame difference. It might very well be placebo.
Tomorrow, I will do a test just for kicks. I will ask someone to launch the same game, one of those that only have 1 frame lag in normal mamen, under the same settings (without vsync or triplebuffer) in both of these emulators out of my view. I will then try to guess which one is running a couple times. Should be fun to see how many times I get it right, if any.
Then I will do the same with vsync on OR triplebuffer on, in shmupmame, and see if I can get it right that time.
It won't prove anything but I'm curious.
It appears the games were slightly more laggy with vsync, and triplebuffer doesn't affect anything. I tested vsync and triplebuffer standalone.
Very heavy emphasis on "appears". I do not trust my senses to be able to tell 1 frame difference. It might very well be placebo.
Tomorrow, I will do a test just for kicks. I will ask someone to launch the same game, one of those that only have 1 frame lag in normal mamen, under the same settings (without vsync or triplebuffer) in both of these emulators out of my view. I will then try to guess which one is running a couple times. Should be fun to see how many times I get it right, if any.
Then I will do the same with vsync on OR triplebuffer on, in shmupmame, and see if I can get it right that time.
It won't prove anything but I'm curious.
"In short, it comes down to spirit" - dodonpachi developper Kohyama.
Re: Input lag
Maybe you should just not do that and practice a game for high scores instead.
Re: Input lag
vsync off? :/ How would that add lag unless your program horribly sucks?
Humans, think about what you have done
Re: Input lag
Being unemployed this winter means I have quite some time on my hands to do both.captpain wrote:Maybe you should just not do that and practice a game for high scores instead.
Normal mame then unlagged mame, with v-sync off.vsync off? :/ How would that add lag unless your program horribly sucks?
"In short, it comes down to spirit" - dodonpachi developper Kohyama.
Re: Input lag
vsync attempts to match a frame with latest screen refresh. Depending on the sync of your game and the speed[and/or stage] of this process likely delays are to be around 0.5 - 1 frames. Typically, with emulation, the implementation of vsync is strictly a separate end process. There are many means of vsync - some with bad consequences - dead space pc anyone?louisg wrote:vsync off? :/ How would that add lag unless your program horribly sucks?
The real issue with realtime graphics - ie. computer games - is that frame rates inevitably vary - even if only slightly. This complicates the issue and most vsyncs, although helping greatly, are still not 100% perfect.
Screen tearing can occur on all types of monitors : Particularly during moments of fast movement, or when frame rates change, which can exasperate other issues where typically one might see the use of motion blur to help with the visual [trick your eye]. Downside of motion blur of course is that it obscures image detail and is typically a post process/double render effect when dealing with real-time graphics - unless this a dedicated part of the renderer(+hardware?) this is another probable frame rate 'risk'.