and, if you drop from 60fps, disabling vsync is good, as you else get 60-30-15fps, i can have everything between, too.. and there is no real difference between 50 and 60 fps.. but "jumps" from 30 to 60 to 30 to 60 to 30 to 60 are visible..

Or you could just use your compilers profiler, because it's going to give a hell of alot more information than the frame rate will. And in any case you shouldn't worry about optimizing anything during developement anyway. That's what alpha testing is for.

hello guys.... i have some quick questions about the vsync story. i dont know if i should start a new thread so sorry if this is the wrong place for this.

davepermen wrote:

and, if you drop from 60fps, disabling vsync is good, as you else get 60-30-15fps, i can have everything between, too.. and there is no real difference between 50 and 60 fps.. but "jumps" from 30 to 60 to 30 to 60 to 30 to 60 are visible..

i have this sometimes in my application. most of the time it runs 60fps but then sometimes 30fps appears. is this because the grafics-pipeline is not balance or something ? or has this to do with alphablending operations ? in my project i have some alpha-blended objects. so ofcourse its the typical effect that appears with alpha-blendings sometimes ?

Die Kharrat wrote:

Well, during development, you would have to do optimizations and also analyize your code. Turning VSync off would tell you the real frames per second of your application.

i remember that i read on few boards that fps over 60fps doesnt really say something.....

FPS is not the optimal measure of how efficient your coding is, but is just a general measure. An FPS of more than 60 is not important in terms of the human eye, where differences between 60 and 70 for example are not noticeable to the human eye.

However, during development, most developers turn vsync off so that they have a better measure of how certain things (adding a model, blending, etc.) affect the FPS.

However, the best way to measure efficiency and to optimize your code is to use a runtime profiler, which is a "tool" for timing bits of your code. You can either write your own or use a commercial one (there might be even free open source ones). With that tool, you'll be able to measure for example what percentage of time a portion of a code took to execute, and the maximum and minimum time peaks it took, etc.

But for general purposes, FPS can work. Here's an article that explains why FPS is not the best way to measure efficiency or optimize code.