General questions about SFML 2.0

[BlueMagic]

First, I want to ask about performance. I've ported the little I had of my 1.6 code to 2.0, and it seems that the performance decreased significantly. It worked at about 2000 FPS with 1.6, but about 700 FPS with 2.0. The only difference is that 1.6 was statically linked, whereas 2 isn't. Is it normal? (maybe the performance increase is found while rendering many objects at a time?)

Also, FPS measurement is now much more imprecise. Since GetFrameTime() and sf::Clocks both use Uint32, the minimum time that we can find is 1 ms, which gives us a top of 1000 FPS when measuring with 1/GetFrameTime(). This also affects the fact that the FPS that we get when we try to lock it or when we use vsync only varies between 2 or 3 values (when using vsync on a 60hz monitor, GetFrameTime mostly returns 16 ms or 17 ms, which results in FPS measurement of 62.5 or 58.8, etc)

Lastly I want to congratulate you and thank you for the constant support that you give and for continuing developing this awesome library.

[Disch]

it seems that the performance decreased significantly. It worked at about 2000 FPS with 1.6, but about 700 FPS with 2.0.

FPS is logarithmic so it's a poor way to test performance.

This is only an increase of less than 1 ms per frame.  I wouldn't exactly call that "significant", but it depends on what you're doing I suppose.

I'll let someone else field the rest, though.

[Laurent]

It worked at about 2000 FPS with 1.6, but about 700 FPS with 2.0. The only difference is that 1.6 was statically linked, whereas 2 isn't. Is it normal?

High FPS values are not relevant at all, you should test with a significant amount of objects.

Also, FPS measurement is now much more imprecise. Since GetFrameTime() and sf::Clocks both use Uint32, the minimum time that we can find is 1 ms, which gives us a top of 1000 FPS when measuring with 1/GetFrameTime(). This also affects the fact that the FPS that we get when we try to lock it or when we use vsync only varies between 2 or 3 values (when using vsync on a 60hz monitor, GetFrameTime mostly returns 16 ms or 17 ms, which results in FPS measurement of 62.5 or 58.8, etc)

But how exactly is this a problem?

[BlueMagic]

Well... Imprecision is a problem when we want precision?

[Disch]

I'm not convinved the old approach (returning time in seconds as a float) was more precise.  In fact in another thread I recall Laurent even said that he never claimed timing functions ever got better than 1 ms precision.

Since GetFrameTime() and sf::Clocks both use Uint32, the minimum time that we can find is 1 ms, which gives us a top of 1000 FPS when measuring with 1/GetFrameTime().

Maybe try using a better method to measure the FPS?  =P

[Laurent]

Well... Imprecision is a problem when we want precision?

Your answer is a little unprecise.
What exactly would you like to get sub-millisecond precision for?

[Contadotempo]

I'm not convinved the old approach (returning time in seconds as a float) was more precise.

Speaking for myself, when I used SFML 1.6 I used to get quasi-stable 60FPS with VerticalSync activated. For me it doesn't make much difference since I have a set FPS limit for the physics and etc... but I'm still curious why this happened. Was it because of the change from float to uint32? Or were the ATI drivers just fooling me when I used SFML 1.6?

Also what other methods are there to retreive FPS? So far I've been using 1000.0/sf::RenderWindow::GetFrameTime().

Thanks  

[Laurent]

Speaking for myself, when I used SFML 1.6 I used to get quasi-stable 60FPS with VerticalSync activated

You get the exact same FPS now, but you can't measure it as precisely as before because of the millisecond limit.

Also what other methods are there to retreive FPS? So far I've been using 1000.0/sf::RenderWindow::GetFrameTime().

You can count the number of frames rendered during 1 second. That could more precise, but the FPS is updated only every second.