-

[Cagar]

-

[Bananamatic]

screen tearing all the way
there is literally nothing wrong with screen tearing if it removes input lag

[Squire Grooktook]

Input Lag is Satan's touch upon the Earth.

[nasty_wolverine]

umm, a well designed game loop, you will never have input lag with vsync.

someone who knows better about arcade PCB's, arent they locked to vsync? its only when you play on mame does it cause a problem, because the vsync rates differ?

[Xyga]

None.

Or v-sync-ed with under one frame of lag, lulz.

[Cagar]

someone who knows better about arcade PCB's, arent they locked to vsync? its only when you play on mame does it cause a problem, because the vsync rates differ?

V-sync causes lag in other games too, not just mame.

mm, a well designed game loop, you will never have input lag with vsync.

How? Because as far as I know, that's not even possible.

[Squire Grooktook]

I thought the idea of Vsync was that it causes lag if your computer isn't able to run the game at 60 fps, because it's jacking things up to synchronize the game's frame-rate and monitor refresh rate. If you can already run it at 60 fps, it's not going to have any effect one way or the other.

[nasty_wolverine]

someone who knows better about arcade PCB's, arent they locked to vsync? its only when you play on mame does it cause a problem, because the vsync rates differ?

V-sync causes lag in other games too, not just mame.

mm, a well designed game loop, you will never have input lag with vsync.

How? Because as far as I know, that's not even possible.

depends on how the game loop was implemented.

emulators will have lag with vsync, because it has to simulate the machines vsync too.

games that integrate time into update loop will have lag with vsync. this is usually done for 3D games where framerate drop should not affect game physics. so you can enjoy your large 3d world at 30 fps without controls going whack.

games that are designed to run at fixed step, meaning all update loops are carried at specific interval, will not benefit from vsync off. this is nostly done for games which need replays, because implementing replays with time integration is extremely difficult. most old school games work like this.

also, if your machine is able to run at full 60fps, then vsync on will not affect input lag. because update time and frame time is the same. when frame rate drops, ofcourse you will see input lag.

this all changes if you have a 120hz monitor.

[Jeneki]

Related to this, has anyone tried a gsync enabled monitor and card with current drivers, and can comment if those cause extra lag or not? The net is full of conflicting and out of date info.

[BareKnuckleRoo]

Anything that reduces input lag is better. Seriously, try the early Touhou games like Embodiment of Scarlet Devil with, and without the V-Sync disabling patch. They play so much better, particularly on Lunatic.

Ideally, you'd have both minimal input lag as well as v-sync, but if you really have to choose one over the other, always, always prioritize input lag.

[TransatlanticFoe]

I run v-sync for modern PC retail games to avoid tearing - when you're moving your aim all over the shop in a third or first person game, tearing is borderline vomit inducing. Only noticed input lag with Dead Space, and even then it was only a problem during a shooting gallery sequence.

For shmups, it's v-sync off to minimse input lag. If there is screen tearing as a result, I haven't ever noticed (MAME, Crimzon Clover, Raiden III, Mushi).

[twotone8]

vsync off most of the time.

for some genres of games, using an external frame limiter to manully set the frameateto to 59 or 58 will allow vsync to be enabled without input lag, and I use that often. It does introduce some slight skipping though.

for shmups and fighting games though, i can definitely forgive some occasional tearing in favor of reduced input lag.

[trap15]

someone who knows better about arcade PCB's, arent they locked to vsync? its only when you play on mame does it cause a problem, because the vsync rates differ?

V-sync causes lag in other games too, not just mame.

mm, a well designed game loop, you will never have input lag with vsync.

How? Because as far as I know, that's not even possible.

depends on how the game loop was implemented.

emulators will have lag with vsync, because it has to simulate the machines vsync too.

games that integrate time into update loop will have lag with vsync. this is usually done for 3D games where framerate drop should not affect game physics. so you can enjoy your large 3d world at 30 fps without controls going whack.

games that are designed to run at fixed step, meaning all update loops are carried at specific interval, will not benefit from vsync off. this is nostly done for games which need replays, because implementing replays with time integration is extremely difficult. most old school games work like this.

also, if your machine is able to run at full 60fps, then vsync on will not affect input lag. because update time and frame time is the same. when frame rate drops, ofcourse you will see input lag.

this all changes if you have a 120hz monitor.

This is a great post This is entirely true, and I'm very curious where the meme of "v-sync always adds input lag" came from. Any properly programmed game that runs at 60Hz will not have any additional input lag with v-sync on.

[nasty_wolverine]

This is a great post This is entirely true, and I'm very curious where the meme of "v-sync always adds input lag" came from. Any properly programmed game that runs at 60Hz will not have any additional input lag with v-sync on.

ya, tell em trap.

vsync off some how creates magical no lag. /s

anyone who understands how vsync and game loops work will know different. it all depends on how the game loop was implemented. older console games and PCBs were always(mostly always?) locked to vsync. its because implementing a separate timer control circuit was either unnecessary or costly. they ran at whatever the consoles or PCBs vsync rate was.

if the game loop implements time integration you will want the game to run as fast as possible. vsync on will create lag if the game runs faster than vsync rate.

if the game update loop is on a fixed time step, vsync on or off should not matter. unless the update step is not synced to vsync, then vsync off will create a slight difference (under 16ms). but if the programmer intentionally implemented a fixed step thats not a multiple of vsync, then he should be fired or look for a better job.

[system11]

Pretty hard to vote in a poll that says 'do you prefer that 1+1 = 3, or that 2+3=4?'

[pegboy]

Screen tearing easily. It won't effect my performance much if at all, unlike input lag.

[Cagar]

As far as I remember, I've yet to see a game that doesn't have any extra input lag with v-sync turned on (not counting arcade games) so I don't know how realistic or common trap's & wolverine's perfect loops are.
Therefore

This is entirely true, and I'm very curious where the meme of "v-sync always adds input lag"

Pretty hard to vote in a poll that says 'do you prefer that 1+1 = 3, or that 2+3=4?'

vsync off some how creates magical no lag. /s

I can't tell if this is nitpicking or unironic pure elitism.
Answer to trap's question: the "meme" probably came from that actually happening!

[Ed Oscuro]

This is a great post This is entirely true, and I'm very curious where the meme of "v-sync always adds input lag" came from. Any properly programmed game that runs at 60Hz will not have any additional input lag with v-sync on.

Agreed, I started questioning this meme recently and discovered that in many games it doesn't add lag. V-sync often should allow the GPU / CPU to idle, also. Unfortunately there are TONS of high profile games and applications that get noticeable lag with v-sync on, so for some games the choice still fits.

tl;dr - Test this setting in every game.

[Cagar]

This is a great post This is entirely true, and I'm very curious where the meme of "v-sync always adds input lag" came from. Any properly programmed game that runs at 60Hz will not have any additional input lag with v-sync on.

Agreed, I started questioning this meme recently and discovered that in many games it doesn't add lag. V-sync often should allow the GPU / CPU to idle, also. Unfortunately there are TONS of high profile games and applications that get noticeable lag with v-sync on, so for some games the choice still fits.

tl;dr - Test this setting in every game.

I'd like to know which games were these, and did they have the option to switch between vsync off-on in the first place?
trap15, nasty_wolverine and system11 could list some examples too.

[Ed Oscuro]

I don't think I could even attempt to list them. What wolverine says about the game loop should be true, but it might be possible for some game to behave differently if hardware or drivers change. Basically, just test out the setting when you see it. Buffer settings can affect input lag, too.

Display Lag.com has an article on input lag in PC games here. They used a simple camera method here, but it should be reliable. They mention a variety of settings that all impact input lag. Unfortunately, they don't cover high framerate settings specifically, though they do cover adaptive sync.

Adaptive sync and high framerates basically obsolete all the previous thinking about input lag and v-sync, though, so if this is really at issue for you, spend a bit of money to get adaptive sync capable hardware.

[Sadd]

It's not a meme. The reason a well designed gameloop won't cause tearing or input latency on old consoles/handhelds or PCBs is because the hardware is directly handling the video output.

Some comments shamelessly stolen from Reddit that explain it better than I could:

On a real SNES, the SNES itself drives the video output. The game updates the video registers during vblank, i.e. while the beam is returning to the top of the screen.
On an emulator, the OS and graphics hardware drive the output. The emulator itself has no control over this. Instead it renders to a framebuffer which the video hardware separately scans from. If the emulator updates this framebuffer while the hardware is mid-scan, there will be tearing, so extra effort is required to keep them synchronised.

Old sprite-and-tile based consoles/computers typically don't use a frame buffer (exceptions being games that use primitive bitmapped 3D rendering like Starfox). The image is drawn in real time at the scan line level. Bear in mind that most games were coded in pure assembly and timing was extremely tight and coders were well aware of the raster line position registers of various consoles/computers. Typically you won't see screen tearing because the code is timed to do all of the scrolling/moving of the tiles/sprites before the raster line gets to the portion of the screen being updated. However, sloppy coding will indeed yield screen tearing. With all that taken into consideration, input lag is pretty much nil. I say all this having programmed extensively on the commodore 64 back in the day.
On the emulation side of things, the emulated machine may think all of the timing is correct but in reality the PC's display vs the emulated display are seldom in sync unless you have cycle-exact timing and emulation. Failing that, the emulator has to do the next best thing which is to render a complete frame of video and buffer it and hold it back until the next or even 2nd next v-blank interval to avoid tearing which will naturally introduce input lag. Even with v-sync off there may still be some lag.

Source: https://www.reddit.com/r/emulation/comm ... mulations/

[nasty_wolverine]

vsync off some how creates magical no lag. /s

I can't tell if this is nitpicking or unironic pure elitism.
Answer to trap's question: the "meme" probably came from that actually happening!

if the game loop implements time integration you will want the game to run as fast as possible. vsync on will create lag if the game runs faster than vsync rate.

if the game update loop is on a fixed time step, vsync on or off should not matter. unless the update step is not synced to vsync, then vsync off will create a slight difference (under 16ms). but if the programmer intentionally implemented a fixed step thats not a multiple of vsync, then he should be fired or look for a better job.

as i said, you do get lesser lag with vsync off in games that do time integrating (which is almost every 3d game). games that employ fixed step updates there is no improvement in lag vsync on or off (most games that have replay, because replay with time integration is a bitch, but some games do manage it), it also forces these kinda games to use hardware backed software timer which is usually less reliable than vsync.

so like ed oscuro said, try it and see what happens. but i will stand by what i said, vsync off will not create magical no lag. it depends on lots of other factors first.

[Cagar]

I've never said nor believed that the no lag is somehow "magical" (where did that implication even come from?), of course it has a deeper technical reason.
Toggling v-sync on or off still affects input lag in the vast majority of games (neither of you couldn't even name a single game where this is not the case), and calling it a "meme" and questioning the sanity of the whole poll is pretty distasteful I think.

[Drake]

Always screen tearing over input lag. I already get upset from the small lag from running games windowed, never mind more substantial stuff.

[Squire Grooktook]

Toggling v-sync on or off still affects input lag in the vast majority of games (neither of you couldn't even name a single game where this is not the case)

On the flip side, how many games can you name where v-sync causes input lag that does not appear when it is turned off? How many games have been tested?

If most pcb's and other games have v-sync, that's a pretty strong argument that it doesn't cause input lag in the vast majority of games.

Again, as I understand it, v-sync only creates input lag if your computer is not already able to run the game at 60 fps. It causes lag by forcing the monitor and game towards the same frame rate. If your computer is already running/refreshing it at 60 fps, then v-sync doesn't actually do anything.

[ED-057]

I guess some games use triple buffering when vsync is on. This adds lag compared to double buffering, but reduces the possibility of missing a frame if it is too slow to render. I see no reason why double buffering with vsync on should have more lag than with vsync off, unless you count seeing part of the next frame a little earlier when the screen tears.

If an emulator was running on a system with enough CPU speed, I suppose it could emulate a whole 1/60th second worth of time on the emulated system during the short v-blank interval of the host system. Then it could have timing pretty close to the real thing.

[Ed Oscuro]

Win10 64 Pro, old Radeon HD 5850 with no DX12 driver support, testing 3D scene performance with v-sync on and off. HL2DM and MW3 both were tested one after the other, and then again, so that I could add a kind of faux-double blind element to the test and forget the v-sync setting:

Killing Floor 2 - seems to have some lag (get to the game ready screen and flick the cursor from side to side), but very slight. Can't really do a controlled test in this one even with a 3D menu; cursor responsiveness isn't as easy to track as moving the viewport.

Half Life 2 Deathmatch - spent a lot of time in this one, in two sessions, confident it's got some lag - hard to determine all the same. "Aero extensions" setting on, default. Changed settings: Raw input, 4X AA, Very High texture detail, motion blur disabled. Moved the viewpoint around two spawns in dm_lockdown. Note: The game menu labels this option "wait for vertical sync," a clue about why many games become less responsive.

Call of Duty Modern Warfare 3 - difficult to judge, again using two sessions, but the game feels very responsive with vertical sync on. Used the Stay Sharp mission from Spec Ops. This game requires you quit to menu to change the v-sync setting. In-game, if there is any lag from v-sync enabled I can't be certain of it. Menus might show a tiny bit of cursor slop with v-sync on, but it's quite small. On the other hand, v-sync Unsure about this one. Now that I've tested this one across two settings, I compared notes with this post - I was hoping there was more perf analysis of this game, but there's still an interesting note there about XP versus Win7.

Counter-Strike: Condition Zero Deleted Scenes (Half-Life GoldSrc engine) - Training level entrance. OpenGL rendering (this game no longer supports DirectX rendering). There might be v-sync related lag here, but it's slight. Even running and then jumping with quick 180 mouse turns to stop movement felt more or less equally good / awkward with either setting. Maybe just a slight feeling of viewport slop with v-sync on when turning, but either setting is more than good enough for playing even at the most difficult setting.

Vanishing of Ethan Carter - just about an equal level of slop in the main menu (background is 3D) with either setting. This game taxes my system so it's not a great choice. Camera smoothing is probably off, but in this menu it's all about cursor movement.

Resident Evil 5 - keyboard and mouse controls. Refresh rate and framerate both set to 60. No AA or motion blur. Turned the camera back and forth at the very beginning of the game, watching scenery high above. Difficult to tell since there's apparently a bit of slop in the view movement anyway. There might be a bit of lag here, but I've played through the entire game with v-sync on and there wasn't anything objectionable. Note: I read a report / rumor that software mouse acceleration is inherent to this game and its sequel.

Dark Souls II - would be more work than I care to put in. For an interesting tangent, Durante has released a predictive framerate cap in GeDoSaTo.

Resident Evil 6 - kb&m, refresh and framerate both set to 60. FXAA, no motion blur. The camera notably lags inputs regardless of setting, but both settings seem very close, including in menus.

" Revelaitons Part The Second - similar settings again, quick menu check of cursor lag - there may possibly be some.

My thoughts: I'm really not terribly confident in these results as a whole, but it is interesting that a number of titles have very responsive controls with movement. Overall, performance is driving responsiveness much more than the v-sync setting, which is as expected. There are also a lot of other potentially confounding variables. I'm also pleasantly surprised that I don't seem to have any games installed at the moment with truly objectionable v-sync related lag on my system (or configured that way) - I've seen some games with very objectionable lag in viewport movement when v-sync is on, but all these games are playable at a pretty high level with vsync on. On the other hand, 60Hz, an old graphics card, and a fairly awful IPS monitor are all limiting factors here. The only saving grace, perhaps, is that I'm using VGA still.

Also, ED-057, triple buffering is faster than double buffering, provided your hardware has got the ability to render that frame. Simple explanation at the usual place. Of course, given the right or wrong implementations, you could get different results. A few things come up in these remarks: This stuff requires esoteric knowledge, or scientific study.

[ZellSF]

Tearing is awful, and I'm really not noticing a huge difference in input lag between vsync+framelimit@refreshrate and novsync.

Console games don't give you the choice though, so it's pretty irrelevant what you prefer.

For PC games, if this is the sort of thing that worries you: get a 120hz+ FreeSync or G-Sync monitor.

[ED-057]

Also, ED-057, triple buffering is faster than double buffering

Like I said, it's faster in terms of hitting a consistent framerate, but it has more lag (we're already rendering the 3rd frame before the 2nd frame has even made it on screen).

I'm starting to think that you and I speak a different language.

[bulbousbeard]

Uh, G-Sync and FreeSync exist in November 2015. This isn't even a question anymore.

You've got a variable refresh monitor, or you're doing it wrong. I feel sorry for anyone who's still eating tearing in November 2015.