Is there any reason not to turn "disable first rate frame lag" off?

[DrFish]

Well... gargorias, can you messure your input lag with and without vsync via "stat engine" command?
I tried it yesterday, but strangely everytime I used this command my fps droped and it became unplayable? Disabling stat engine my fps went norma. I cant explain that...

I can..

If you turn that on, it works like a trace output of an application you're debugging. It gives info about many things on each cycle, so the performance might drop because, say it would calculate some statistic on every pixel relocation.

[demoniac]

I can..

If you turn that on, it works like a trace output of an application you're debugging. It gives info about many things on each cycle, so the performance might drop because, say it would calculate some statistic on every pixel relocation.

It works nothing like debugging. There's no real-time watch on addresses, no symbol information being passed back and forth. The ov0rhead should be nowhere near that of a debugg0r.

[Fliperaci]

I can..

If you turn that on, it works like a trace output of an application you're debugging. It gives info about many things on each cycle, so the performance might drop because, say it would calculate some statistic on every pixel relocation.

Thanks for your replies!
So these calculations are related to my CPU? Maybe playing with 32bots was too much and caused fps drops. Killing all bots gave me my regularly fps (with stat engine). It seems that my e8400 @ 3,5 Ghz is too weak to do this calculations with bots :-/
It would be nice if you can do it or someone else.

It works nothing like debugging. There's no real-time watch on addresses, no symbol information being passed back and forth. The ov0rhead should be nowhere near that of a debugg0r.

Well, but what was it instead? I didnt change anything... maybe I am just not getting your point :O

[Benfica]

It works nothing like debugging. There's no real-time watch on addresses, no symbol information being passed back and forth. The ov0rhead should be nowhere near that of a debugg0r.

Sigh, what do you know about debugging if you can't do that even to your own posts?

[CaptainSnarf]

This is what happens without vsync:

Your lcd 

|~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|                           |
|                           |  <----      Frame 1
|                           |
|___________________________|
|                           |
|                           |  <----      Frame 2
|                           |
|___________________________|

The screen draws from top to bottom. If frame 2 is finished being computed before the screen is finished drawing frame 1, you will see half of frame 1 and half of frame 2 like the picture shows above. This is called tearing.

Because frame 2 is most likely very similar graphically to frame 1, the tearing is usually not noticeable. A quick change of scene such as an explosion happening can make it much more noticeable. If an explosion happens on the screen, the top half of the screen might still be the old frame while the bottom half is the explosion frame, the line between becoming very noticeable, but since it is corrected in the next frame, it's not as noticeable as you'd think.

Say you are in a fast paced battle. You are looking forward and frame 1 renders. During that rendering you move your mouse. The next engine tick has you looking 90 degrees to the right and shoot. With tearing, the second frame will render immediately. If there is an enemy to the right, for an instant, you will only see his feet, the top of the screen still displaying the first frame. As soon as the bottom of frame 2 is rendered it is continued at the top until frame 3 is rendered, which again results in more tearing.

No matter how you slice it, there is going to be a line between frame 1 and frame 2. With v-sync, the line is moved to the bottom/top of the screen in between frames so you don't see it. The only way for the engine to move it is to either render faster (which it's already rendering as fast as it can) or to wait. That wait equals lag, which means v-sync causes lag.



Now lets see what happens with your CRT:

CRT

 No vsync
|~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|                           |
|                           |  <----      Frame 1
|                           |
|___________________________|
|                           |
|                           |  <----      Frame 2
|                           |
|___________________________|
|___________________________| <- vertical blank period


 with vsync
|~~~~~~~~~~~~~~~~~~~~~~~~~~~|
|                           |
|                           |  <----      Frame 1
|                           |
|                           |
|                           |
|                           |
|___________________________| <- end of frame 1
|___________________________| <- vertical blank period


     buffer
    |~~~~~~~~~~~~~~~~~~~~~~~~~~~|
    |                           |
    |                           |  <----      Frame 2 waiting in
    |                           |                a buffer to be flipped
    |                           |
    |                           |
    |                           |
    |___________________________|

v-sync lag is usually not noticeable on a CRT monitor. This is because CRT monitors already have a lag between frames called the vertical blank period (this is what you are supposed to sync against). Since there is already a lag, adding the v-sync lag just lines up both lags together so the image doesn't distort. In this case it actually doesn't cause any lag (it's already thre in the vblank), but simply adjusts the timing of everything to match your monitor's already inherent lag. With v-sync, because the monitor and the game engine tick() are working in harmony, and depending on the engine this can result in a better gameplay experience and actually less lag because of better synchronization. It's only true of CRT monitors though. There is no vertical blank period in LCDs. For LCDs enabling vsync may remove tearing at the cost of a slight bit of lag.

[Jov4s]

I actually dont really care anymore.. Im having constant 60 fps maxed out, vsync on. Ocassionally drops to 45, but very rarely during heavy combat.. And yes, i get better framerates and gameplay with the ``OFTL`` box unthicked.

After three months im starting to get used to my new rig, and UT3, i actually end on top of the list more often lol..

Whats interesting for me is to know if my stock i7 920 or stock HD4850 is bottlenecking my system and causing the framedrops.

[gargorias]

I actually dont really care anymore.. Im having constant 60 fps maxed out, vsync on. Ocassionally drops to 45, but very rarely during heavy combat.. And yes, i get better framerates and gameplay with the ``OFTL`` box unthicked.

After three months im starting to get used to my new rig, and UT3, i actually end on top of the list more often lol..

Whats interesting for me is to know if my stock i7 920 or stock HD4850 is bottlenecking my system and causing the framedrops.

Okay, this took some time but here you go.
Using UT3 Benchmark tool with texture and level details on 5 with sound on and DX10 box ticked.
10 runs of DM-Shangrila with 12 bots.
Screen resolution - 2560x1600

Overclock at 3.6 the average FPS was 68.46
Default clock of 2.66 the average FPS was 66.95

I think the results are that close that they would justify the statement that UT3 doesn't trouble the i7 920 even at default clocks.

And for those interested my NVCP settings that I use for UT3:
AA and AF at 16x
Texture Filtering quality on high.
Negative lod bias on clamp.
AA gamma correction on.
AA transparency on Multisampling.
Maximum pre-rendered frames on 3.
Triple buffering on.

NB:Yes I know it's 3.8 in my sig that was a mistake I haven't corrected yet.

[Jov4s]

Okay, this took some time but here you go.
Using UT3 Benchmark tool with texture and level details on 5 with sound on and DX10 box ticked.
10 runs of DM-Shangrila with 12 bots.
Screen resolution - 2560x1600

Overclock at 3.6 the average FPS was 68.46
Default clock of 2.66 the average FPS was 66.95

I think the results are that close that they would justify the statement that UT3 doesn't trouble the i7 920 even at default clocks.

And for those interested my NVCP settings that I use for UT3:
AA and AF at 16x
Texture Filtering quality on high.
Negative lod bias on clamp.
AA gamma correction on.
AA transparency on Multisampling.
Maximum pre-rendered frames on 3.
Triple buffering on.

NB:Yes I know it's 3.8 in my sig that was a mistake I haven't corrected yet.

Thanks, thats what i thought..

[Jov4s]

Still I`d like to see what happens if you run a map like Confrontation or Serenity with 32 bots. No framedrops there?

[MAshling]

i found that it does increase mouse sesitivity but it also added a slight delay in firing so had to change it back