V Sync and Triple Buffering

[theREALikillu]

I had some sort of delay in ET, hit boxes way off, not able to hit anyone. VSYNC was off and solved it, but the game wasn't playable, too much tearing. Anyone else have vsync enabled, but did away with the delay vsync incorporates? I enable vsync in nvidia control panel and in my cfg, but I do not enable triple buffering, then I set the game refresh in my cfg to 57 or so, this is supposed to do away with delays. Does anyone else use a similar technique to enable vsync, but not suffer from the delay it brings? I also limit the game affinity in task manager to 1 core, and set priority to realtime, I have a quad core intel chip and a gtx 275 card. Hyper threading is off in my cfg and Nvidia control panel too. What do you guys think? Should I just get a life and deal with the delay or am I hallucinating that the delay is gone or, I'm confused, what does everyone else do about delay?

 

[PiNoY]

Hmmm..interesting. Wanna share your config on enabling and disabling those, wanna keep learning you know before I grow older LOL

[Waster]

if you have vsync on then you need to set your config for whatever your desktop display refresh rate is at. Since it tries to match or sync that refresh rate.

Triple buffering adds to your delay, I have it turned off in my nvidia control panel.

[theREALikillu]

It's a modified version of hobbit's hobpublic cfg file, some of the changes made in it I fully understand, a lot of the changes were educated guesses, very few I had no clue and took a wild guess. My main problem was tearing and vsync solved it but issued a delay, which seems to have been corrected with changes in nvidia control panel and cfg as listed above in my initial post.

 

From what I've read if you lower the framerate in the game cfg from 60 to 59 or in some games as low as 57 then the delay is non-existent with vsync on and triple buffering off. It seems to be working, hopefully not just my imagination.

 

// Hobbit Rip Off Config.
//Updated: 2-22-12
// [connexion]
seta rate "25000"
seta snaps "20"
seta cl_maxpackets "75"
seta cl_timenudge "0"
seta cl_doubletapdelay "0"
seta pb_security "0"
seta pb_sleep "500"
seta cl_packetdup "0"
seta cl_pitchspeed "0"
seta cl_yawspeed "0"
// [controlz]
seta com_maxfps "60"
seta cg_fov "100"
seta in_mouse "-1"
seta sensitivity "1.6"
seta cl_mouseaccel "0"
seta m_pitch "0.016"
seta m_yaw "0.020"
seta m_filter "0"
seta cg_drawfps "1"
seta cg_drawGun "0"
seta cg_errordecay "0"
// [Crosshair]
seta cg_drawcrosshair "5"
seta cg_crosshaircolor "fff00"
seta cg_crosshairhealth "0"
seta cg_crosshairpulse "0"
seta cg_crosshairsize "22"
seta cg_crosshairHealth "0"
seta cg_drawCrosshairNames "1"
seta cg_drawCrosshairPickups "1"
seta r_useThreadedRenderer "0"
seta r_mode "-1"
seta r_customaspect "2"
seta com_unlock_timingMethod "0"
seta com_unlock_maxfps "60"
seta com_unlock_avgFrames "0"
seta r_displayRefresh "57"
seta r_nv_fogdist_mode "GL_EYE_RADIAL_NV"
seta com_unlockFPS "1"
seta r_ati_fsaa_samples "0"
seta r_ati_truform_tess "0"
seta r_ext_ATI_pntriangles "0"
seta r_finish "1"
seta r_lightmap "0"
// [r_settings]
seta r_customwidth "1920"
seta r_customheight "1200"
seta r_swapInterval "1" // vsync 0 is off 1 on
seta r_gamma "3" //Changed from 2.4
seta r_picmip "0"
seta r_overbrightbits "1"
seta r_mapoverbrightbits "2" //changed from 3
seta r_fullbright "1"
seta r_intensity "1.5"
seta r_ingamevideo "0"
seta r_ignorehwgamma "1"
seta r_flares "0"
seta r_drawsun "0"
seta r_fastsky "1"
seta r_showsky "0"
seta r_subdivisions "80"
seta r_simpleMipMaps "1"
seta r_detailtextures "1"
seta r_ext_gamma_control "1"
seta r_textureMode "GL_LINEAR_MIPMAP_LINEAR"
seta r_texturebits "32"
seta r_colorbits "32"
seta r_stereo "0"
seta r_stencilbits "0"
seta r_depthbits "32"
seta r_vertexLight "1"
seta r_shownormals "0"
seta r_showmodelbounds "0"
seta r_dynamiclight "0"
seta r_lodbias "2"
seta r_primitives "0"
seta r_clamptoedge "0"
seta r_ext_compiled_vertex_array "1"
seta r_ext_compressed_textures "1"
seta r_ext_nv_fog_dist "1"
seta r_ext_texture_filter_anisotropic "1"
seta r_drawfoliage "0"
seta r_lodCurveError "0"
// v shit
seta v_kicktime "0"
seta v_kickroll "0"
seta v_kickpitch "0"
// [cg_settings]
seta cg_bloodflash "0"
seta cg_bloodDamageBlend "0"
seta cg_bloodtime "0"
seta cg_drawWeaponIconFlash "0"
seta cg_drawReinforcementTime "1"
seta cg_noAmmoAutoSwitch "1"
seta cg_complaintPopUp "0"
seta cg_draw3dicons "0"
seta cg_autoReload "0"
seta cg_useScreenshotJPEG "1"
seta cg_printObjectiveInfo "1"
seta cg_atmosphericEffects "0"
seta cg_wallmarklifetime "0"
seta cg_teamchattime "6000"
seta cg_drawcompass "1"
seta cg_drawfireteamoverlay "1"
seta cg_drawSmallPopupIcons "1"
seta cg_hudAlpha "1.0"
seta cg_muzzleFlash "0"
seta cg_brassTime "0"
seta cg_simpleitems "1"
seta cg_gibs "0"
seta cg_shadows "0"
seta cg_marktime "0"
seta cg_coronas "0"
seta cg_coronafardist "0"
seta cg_showblood "0"
seta cg_lagometer "1"
seta cg_popuplimbomenu "0"
seta cg_drawNotifyText "1"
seta cg_descriptiveText "1"
seta cg_drawTeamOverlay "2"
seta cg_autoAction "5"
seta cg_announcer "1"
seta cg_gun_frame "0"
seta cg_drawroundtimer "1"
seta cg_drawbuddies "1"
seta cg_drawfallkick "0"
seta cg_fallkick "0"
seta cg_damagekick "0"
seta cg_drawdamagekick "0"
seta cg_weaponcycledelay "0"
seta cg_bobup "0"
seta cg_bobpitch "0"
seta cg_bobroll "0"
seta cg_runpitch "0.002"
seta cg_runroll "0.005"
seta cg_bobyaw "0"
seta cg_wolfparticles "0"
seta cg_railTrailTime "0"
seta cg_impactvibration "0"
seta cg_blinktime "0"
// [com_settings].
seta com_hunkMegs "1024"
seta com_zoneMegs "512"
seta com_soundMegs "64"
seta com_blood "0"
seta com_crashed "0"
// [b_settings]
seta b_optimizePrediction "0"
seta b_popuptime "0"
seta b_drawclock "0"
seta b_althud "2"
seta b_althudflags "7"
seta b_fireteamalpha "1"
seta b_drawranks "0"
seta b_tracers "0"
seta b_muzzleflash "0"
seta b_hitsounds "1"
seta b_drawpromotions "0"
seta b_drawrewards "0"
seta b_simpleitems "0"
seta b_antilag "0" // lag bullet control by server
seta s_mixahead "0.12"
seta s_mixprestep "0.05"
seta s_loadas8bit "1"
seta s_compression "1"
seta s_khz "44"
seta s_musicvolume "0"
seta s_doppler "1"
seta s_Volume "0.10"
seta s_separation "0.5"
seta s_defaultsound "0"
seta s_wavonly "0"
seta timescale "1"
seta s_useocclusion "0"

[deadpnk]

vsync and triple buffering are lagaholics as i'm sure u know, so far there is NOTHING to solve that given what i have known, closest thing to lagless play would be to use hardware cursor on top of that?:

 

but ET has no option to use hardware cursor, it was developed on XP since it came out so there isn't exactly a way for ET to bypass windows' mouse control because hardware cursor involves the graphics API. and et's graphics are old laggy weaksauce (i get better fps average playing wow with all the eye candy than ET)

 

srsly, your kinda SOL on this man, id prefer taking off the eye candy to have some lagless candy.

 

 

imo take off the vsync and triple buffering, and raise your fps cap to 125 or higher, you don't really notice all that tearing because the frames are coming in so fast your monitor's refresh rate would quickly have like a small tear if you looked at it closely.

[vke]

Real time priority is retarded. Changing the priority doesn't do anything, unless you only have a single core processor. Keep it on normal. What vsync does is force your fps to your monitors framerate. Much better to have it off actually, unless you have a monitor with 120hz refresh. You will actually have more delay and choppiness with vsync and triple buffering compared to with it off. I would recommend 125 fps, with a quad core and a 275 you should be able to get it, even at max resolution. 60 is handicapping you, since et performs best at 71, 76, and 125. With 125 you generally move faster, shoot more accurately, and jump further/higher.

 

Also, are you using beta drivers from nVidia? If you are, roll them back to the latest stable version and see if that helps.

[PiNoY]

Do you have a big screen from your end? Because your config has a wide height and width, which decreases FPS performance somehow imo. Try capping your FPS to a higher one like 76 or 125 as mentioned above.Or while you are troubleshooting with your config, set it to 0 so that you can see what config makes your FPS number good or bad, and which one gave you higher stable FPS

 

I loaded your config, issue vid_restart and I did not get that delay or lag that you were referring to. Your config is more crispy than mine. So I am guessing the problem you are having is Nvidia setup related.

 

 

Just to let you know, I had this experience wherein the latest nvidia driver lowers down my stable FPS. So I always use the one that offered me a higher stable FPS . Google for 40.41_winxp , it is an old nvidia driver installer that gave me 76 stable FPS and at times makes my base race jumping faster, which I really cant figure out how I did that, it's like being ejected in fast mode. Yesterday, I tried the latest Nvidia package driver again and same results of low stable FPS of 43 only.

[SunLight]

vsync always lagged my mouse movements, and I never used it for that reason.

I don't think it's possible to use vsync without mouse lags, maybe if you set com_maxfps to something below your refresh rate, but it would still suck imho.

In the past I tried that, and it didn't lag much, but still felt much worse than125fps and no vsync at all. I prefer to have tearing (it's barely noticeable with high fps) and have less mouse delay.

 

p.s.

Jumping higher with 125 fps is an old feature, it's been years since etpro configs started using b_fixedphysics, and gaymod and other mods later copied that thing from etpro, as usual (yes I know, I am biased). So jump height should be the same regardless of your fps, and in double jump servers it shouldn't be an issue anyway.

And no, hitboxes cannot be 'off', but if your whole view is delayed you obviously can't aim well. Imho the use of the word hitboxes should be forbidden to non-modders, because they never get it right... -.-

 

p.p.s.

in that config you have b_antilag 0 (that is, antilag disabled on etpro)? Not going to help your accuracy for sure...

[BossHK]

I'll copy & paste a wise man words:

 

What is VSync? VSync stands for Vertical Synchronization. The basic idea is that synchronizes your FPS with your monitor's refresh rate. The purpose is to eliminate something called "tearing". I will describe all these things here.

 

Every CRT monitor has a refresh rate. It's specified in Hz (Hertz, cycles per second). It is the number of times the monitor updates the display per second. Different monitors support different refresh rates at different resolutions. They range from 60Hz at the low end up to 100Hz and higher. Note that this isn't your FPS as your games report it. If your monitor is set at a specific refresh rate, it always updates the screen at that rate, even if nothing on it is changing. On an LCD, things work differently. Pixels on an LCD stay lit until they are told to change; they don't have to be refreshed. However, because of how VGA (and DVI) works, the LCD must still poll the video card at a certain rate for new frames. This is why LCD's still have a "refresh rate" even though they don't actually have to refresh.

 

I think everyone here understands FPS. It's how many frames the video card can draw per second. Higher is obviously better. However, during a fast paced game, your FPS rarely stays the same all the time. It moves around as the complexity of the image the video card has to draw changes based on what you are seeing. This is where tearing comes in.

 

Tearing is a phenomenon that gives a disjointed image. The idea is as if you took a photograph of something, then rotated your vew maybe just 1 degree to the left and took a photograph of that, then cut the two pictures in half and taped the top half of one to the bottom half of the other. The images would be similar but there would be a notable difference in the top half from the bottom half. This is what is called tearing on a visual display. It doesn't always have to be cut right in the middle. It can be near the top or the bottom and the separation point can actually move up or down the screen, or seem to jump back and forth between two points.

 

Why does this happen? Lets take a specific example. Let's say your monitor is set to a refresh rate of 75Hz. You're playing your favorite game and you're getting 100FPS right now. That means that the mointor is updating itself 75 times per second, but the video card is updating the display 100 times per second, that's 33% faster than the mointor. So that means in the time between screen updates, the video card has drawn one frame and a third of another one. That third of the next frame will overwrite the top third of the previous frame and then get drawn on the screen. The video card then finishes the last 2 thirds of that frame, and renders the next 2 thirds of the next frame and then the screen updates again. As you can see this would cause this tearing effect as 2 out of every 3 times the screen updates, either the top third or bottom third is disjointed from the rest of the display. This won't really be noticeable if what is on the screen isn't changing much, but if you're looking around quickly or what not this effect will be very apparant.

 

Now this is where the common misconception comes in. Some people think that the solution to this problem is to simply create an FPS cap equal to the refresh rate. So long as the video card doesn't go faster than 75 FPS, everything is fine, right? Wrong.

 

Before I explain why, let me talk about double-buffering. Double-buffering is a technique that mitigates the tearing problem somewhat, but not entirely. Basically you have a frame buffer and a back buffer. Whenever the monitor grabs a frame to refresh with, it pulls it from the frame buffer. The video card draws new frames in the back buffer, then copies it to the frame buffer when it's done. However the copy operation still takes time, so if the monitor refreshes in the middle of the copy operation, it will still have a torn image.

 

VSync solves this problem by creating a rule that says the back buffer can't copy to the frame buffer until right after the monitor refreshes. With a framerate higher than the refresh rate, this is fine. The back buffer is filled with a frame, the system waits, and after the refresh, the back buffer is copied to the frame buffer and a new frame is drawn in the back buffer, effectively capping your framerate at the refresh rate.

 

That's all well and good, but now let's look at a different example. Let's say you're playing the sequel to your favorite game, which has better graphics. You're at 75Hz refresh rate still, but now you're only getting 50FPS, 33% slower than the refresh rate. That means every time the monitor updates the screen, the video card draws 2/3 of the next frame. So lets track how this works. The monitor just refreshed, and frame 1 is copied into the frame buffer. 2/3 of frame 2 gets drawn in the back buffer, and the monitor refreshes again. It grabs frame 1 from the frame buffer for the first time. Now the video card finishes the last third of frame 2, but it has to wait, because it can't update until right after a refresh. The monitor refreshes, grabbing frame 1 the second time, and frame 2 is put in the frame buffer. The video card draws 2/3 of frame 3 in the back buffer, and a refresh happens, grabbing frame 2 for the first time. The last third of frame 3 is draw, and again we must wait for the refresh, and when it happens, frame 2 is grabbed for the second time, and frame 3 is copied in. We went through 4 refresh cycles but only 2 frames were drawn. At a refresh rate of 75Hz, that means we'll see 37.5FPS. That's noticeably less than 50FPS which the video card is capable of. This happens because the video card is forced to waste time after finishing a frame in the back buffer as it can't copy it out and it has nowhere else to draw frames.

 

Essentially this means that with double-buffered VSync, the framerate can only be equal to a discrete set of values equal to Refresh / N where N is some positive integer. That means if you're talking about 60Hz refresh rate, the only framerates you can get are 60, 30, 20, 15, 12, 10, etc etc. You can see the big gap between 60 and 30 there. Any framerate between 60 and 30 your video card would normally put out would get dropped to 30.

 

Now maybe you can see why people loathe it. Let's go back to the original example. You're playing your favorite game at 75Hz refresh and 100FPS. You turn VSync on, and the game limits you to 75FPS. No problem, right? Fixed the tearing issue, it looks better. You get to an area that's particularly graphically intensive, an area that would drop your FPS down to about 60 without VSync. Now your card cannot do the 75FPS it was doing before, and since VSync is on, it has to do the next highest one on the list, which is 37.5FPS. So now your game which was running at 75FPS just halved it's framerate to 37.5 instantly. Whether or not you find 37.5FPS smooth doesn't change the fact that the framerate just cut in half suddenly, which you would notice. This is what people hate about it.

 

If you're playing a game that has a framerate that routinely stays above your refresh rate, then VSync will generally be a good thing. However if it's a game that moves above and below it, then VSync can become annoying. Even worse, if the game plays at an FPS that is just below the refresh rate (say you get 65FPS most of the time on a refresh rate of 75Hz), the video card will have to settle for putting out much less FPS than it could (37.5FPS in that instance). This second example is where the percieved drop in performance comes in. It looks like VSync just killed your framerate. It did, technically, but it isn't because it's a graphically intensive operation. It's simply the way it works.

 

All hope is not lost however. There is a technique called triple-buffering that solves this VSync problem. Lets go back to our 50FPS, 75Hz example. Frame 1 is in the frame buffer, and 2/3 of frame 2 are drawn in the back buffer. The refresh happens and frame 1 is grabbed for the first time. The last third of frame 2 are drawn in the back buffer, and the first third of frame 3 is drawn in the second back buffer (hence the term triple-buffering). The refresh happens, frame 1 is grabbed for the second time, and frame 2 is copied into the frame buffer and the first part of frame 3 into the back buffer. The last 2/3 of frame 3 are drawn in the back buffer, the refresh happens, frame 2 is grabbed for the first time, and frame 3 is copied to the frame buffer. The process starts over. This time we still got 2 frames, but in only 3 refresh cycles. That's 2/3 of the refresh rate, which is 50FPS, exactly what we would have gotten without it. Triple-buffering essentially gives the video card someplace to keep doing work while it waits to transfer the back buffer to the frame buffer, so it doesn't have to waste time. Unfortunately, triple-buffering isn't available in every game, and in fact it isn't too common. It also can cost a little performance to utilize, as it requires extra VRAM for the buffers, and time spent copying all of them around. However, triple-buffered VSync really is the key to the best experience as you eliminate tearing without the downsides of normal VSync (unless you consider the fact that your FPS is capped a downside... which is silly because you can't see an FPS higher than your refresh anyway).

 

I hope this was informative, and will help people understand the intracacies of VSync (and hopefully curb the "VSync, yes or no?" debates!). Generally, if triple buffering isn't available, you have to decide whether the discrete framerate limitations of VSync and the issues that can cause are worth the visual improvement of the elimination of tearing. It's a personal preference, and it's entirely up to you.

 

Btw, ET can't use triple buffering, right?

Edited February 25, 2012 by BossHK

[SunLight]

Btw, ET can't use triple buffering, right?

hmm I am not sure, but every time I turn vsync on I get a mouse lag, as if all my movements were recorded and replayed with a delay. So it's not only about fps going down to half. It feels as if everything is being rendered without being displayed, then shown with a delay. It's not the same feeling as setting, let's say, 30fps without vsync.

Which is strange, because your mouse position is supposed to be read only once per frame.

 

I never checked how the game waits for vertical refresh, but it seems it's either poorly implemented or it's a common problem for all games when using vsync.

Because some years ago I wanted to use vsync, I did some research to see if I could set some parameter in my gfx card to get rid of that mouse lag, but nothing.

[theREALikillu]

Ok, took the advice here, vsync off 125fps ... it's working well, sometimes my fps drop sometimes they don't ... no more lag from what I can tell. I also set antilag to 1 from 0, if that makes a difference. Thanks!

[SunLight]

Ok, took the advice here, vsync off 125fps ... it's working well, sometimes my fps drop sometimes they don't ... no more lag from what I can tell. I also set antilag to 1 from 0, if that makes a difference. Thanks!

b_antilag (like all cvars starting with b_) is an etpro cvar, so it only affects that mod, if you don't play etpro you won't see a difference.

 

b_antilag 0 means disable antilag.

That means, you can't aim at the player, but you have to lead the target. The higher your ping is, the more you have to lead. Since nobody can predict the future, it's obvious that without antilag you will end up having a lower accuracy, that's why I told you to set it to 1. But it's only for etpro it won't affect your aim in other mods.

[PiNoY]

if i turned off vsync and triple buffering, my FPS doubles

[Glyphz]

if you find threaded optimization in your Nvidia control panel turn it off

[PiNoY]

yes, threaded optimization is off but Texture filtering is on. I also have maximum pre-rendered frames set to 0, and it works fine although the default is 3.