asmo wrote:My FPS taken like psi29a described is 60 FPS with almost all graphics options set to maximum. VSync, ...

Do you mean with VSync enabled? Because that would lock FPS to your screen refresh rate, which probably is 60.

Ah ... good to know, I'll update my info in the benchmarks thread.

(NEW)
I just turned "Vertical Sync" off. But there was not much difference. When I stand in Balmora it's around 80 (which is a difference to 60 FPS). When moving it looks like as there is no difference. At the "bottleneck" mentioned at my last post FPS goes down to 32 fps (when moving in first person, with rain, thunder and lightning).

For those who don't know what VSync is or what it does... (Also keep in mind that I'm not an expert, and I'm just going based off of the random trivia I've acquired during my time on the internet.)

Every monitor is designed to display a certain number of frames over a given time, for example, 60 frames per second. As I understand it, it will always display at 60 FPS, no exceptions. If you are playing a game that is running higher than 60 FPS, your monitor will still lock it at 60 FPS. If you are playing a game that runs slower than 60 FPS, your monitor will get around this by displaying the same frame more than once, typically downgrading your FPS to 30 (show every frame twice), 20 (show every frame three times), 15 (show every frame four times), et cetera. But this is only if you have VSync turned on.

Okay, now let's get a bit more technical. What's actually going on is that your graphics card (GPU) is drawing a frame, and then your monitor is grabbing that frame and displaying it. Your GPU is, however, not limited to 60 FPS like your monitor is, and will start drawing a new frame as soon as it's done with the old one. Without VSync, what will happen is that your GPU will draw a frame, then begin drawing the next frame on top of the old one. You monitor will grab whatever image the GPU has prepared, which can be part of one frame and part of another, leading the image to look "torn". (Imagine taking two pictures with a camera, cutting them in half, and then taping half of one picture to half of the other picture. It's not so bad when the picture is of a still object, but if it's of something moving quickly, or if the pictures are at slightly different angles, it becomes much more noticeable.) All VSync does is insure that the monitor only grabs complete frames.

Basically, with VSync, you avoid screen tearing, but the tradeoff is that FPS will always be downgraded to a lower level to insure smoothness. If you are getting 45 FPS, it doesn't actually matter, since you'll only see 30 FPS. You have to push your FPS to 60 or higher before you'll see an improvement from 30 FPS. Now, this isn't totally true as FPS generally tends to fluctuate during play, so having 45 FPS means you're less likely to dip below 30 during an intense moment.

Of course, this only applies to graphics. Some games use frames as a means of measuring time in-game. In some poorly designed games, running at a lower or higher FPS than what it was designed for can affect things like physics, AI, or the speed at which the game runs.

At least, that's how I understand VSync to work. If I'm wrong about anything, feel free to correct me.

The more you know
================*

I know no one asked for this. I can't help it, I'm a compulsive explainer.

Greywander wrote:Basically, with VSync, you avoid screen tearing, but the tradeoff is that FPS will always be downgraded to a lower level to insure smoothness.

In more recent years, with OpenGL, there's an EXT_swap_control_tear extension that alleviates this somewhat. Basically what the extension does is it checks if the rendered buffer is on time (before the monitor has displayed its next frame), and if so, will wait like normal. But if it's late, it will show it right away regardless. This means that if you maintain 60+FPS (or whatever your monitor refresh rate is) you still avoid screen tearing and get limited to 60, while if it drops below it will cause tearing but avoid dropping the FPS down to the next divisor.

Of course, just to confuse things further, even more recently there's something called G-Sync. This basically flips everything on its head so that, rather than the monitor displaying a frame 60 (or whatever) times a second using whatever the video card has, the monitor will instead wait for the video card to say "here, a new frame is ready" and then display it, regardless of how long it takes (there is still an upper limit because of physical limitations, but it completely avoids tearing since the monitor will only show frames when the video card says it's ready).

If I got it right, what's displayed by the game engine is what the graphics card can/does supply. However, I can physically only get 60fps displayed because that's the max. VSync (max frame rate) of my monitor.
I guess that's what's still common (max VSync 60Hz) so when we provide "benchmark results" here the purpose is to find bottlenecks and planning how much the code has to be optimised to give a good frame rate for features like shadows and reflections.

asmo wrote:If I got it right, what's displayed by the game engine is what the graphics card can/does supply. However, I can physically only get 60fps displayed because that's the max. VSync (max frame rate) of my monitor.

Basically yeah.

I guess that's what's still common (max VSync 60Hz) so when we provide "benchmark results" here the purpose is to find bottlenecks and planning how much the code has to be optimised to give a good frame rate for features like shadows and reflections.

Between 60 and 80 is common (some can go up to 120, and as mentioned, newer G-Sync stuff changes the playing field considerably).

A good benchmark tool wouldn't use framerate since that metric's subject to several outside factors, including vsync. A better method is to test the time it takes to do something, such as how fast the video card renders the scene, rather than how many times it can render a scene per second. You could even subdivide it and measure how fast it can render different parts of the scene (such as the reflections, the shadow map(s), etc), to get a clearer understanding of where bottlenecks are.