SFML 2.0: GetFrameTime

[Contadotempo]

Hi,
I've updated SFML 2.0 to the latest snapshot today and for some reason whenever I use GetFrameTime it's returning me 15.0 while I'm limiting the frames to 60.
I've confirmed that the frames are limited to 60 with Fraps but the function seems to return a strange value. Were there any changes on this function lately? I can't find anything on the documentation.

Also EnableVerticalSync doesn't seem to work anymore. The frames fire up to 5000 when I'm using it and GetFrameTime returns 0.

Everything worked fine before I've updated so I don't know what could be wrong. Compiled with VS10 and CodeBlock's MinGW and both act like this.

Thanks in advance for any input.

[Hiura]

Now sf::Window::GetFrameTime returns milliseconds as sf::Uint32 (see the doc)

[Contadotempo]

Yeah, whoops, right after I finished posting I saw it on github. Thanks.
But still, how come EnableVerticalSync doesn't seem to work now?

Was anything changed on this one?

[Laurent]

Nop, but v-sync can be forced off in the graphics driver.

[Contadotempo]

That's probably what happened.
For some reason after using remote screen on Skype (me sharing my screen image), every-time I launch an SFML based application, EnableVerticalSync doesn't seem to work.
I'm guessing it's a driver problem or a bug in Skype.
After restarting the computer it's fine again.

I do have one more question by the way:
I'm trying to convert the FrameTime into Frames per second, and I'm using each frame:

Code: [Select]

float lastfps = 1000.0 / Target.GetFrameTime();

I wanted to ask if this is the best practice. Whenever the real FPS goes over 1000 the counter displays "1.#10". Sorry, I don't really understand how Uint32 works.

Thanks for the help so far.

[Laurent]

GetFrameTime() will sometimes return 0 if your FPS is greater than 1000 (ie. frame time is less than 1 ms), so you end up dividing by zero.

[Contadotempo]

Ah I understand, thanks.
If you don't mind me asking, what was the reason to change the number precision to milliseconds? Does it offer more exact values closer to the ideal situation? Don't understand me wrong though, I'm not complaining, just curious.

Thanks  

[Laurent]

Everything's explained in the dedicated topic on the General forum

[Contadotempo]

Whoops, I'm sorry as I didn't notice there was already a topic for it.
Thanks for all the help.

[Contadotempo]

Sorry for bumping the topic once again but I think this doesn't deserve another thread:

SetFramerateLimit(60) doesn't seem to be working correctly now (vsync disabled).
I get around ~67 - 66 FPS (confirmed with FRAPS) and before updating SFML I was able to get constant 60. It's not a big issue but what could be wrong here?

Thanks.

[Laurent]

Can you try with the revision *before* the one that changed times to Uint32?

[Contadotempo]

Yes, I recompiled the commit from 2011-05-15 and it seems to limit the frames to exact 60 again (Confirmed with FRAPS).

[Laurent]

It's strange, I checked the new code again and everything's ok. With rounding you could have 62.5 but not 67. I guess the difference is due to the resolution of the Sleep function on Windows.

[Contadotempo]

Yesterday I was able to. This morning I can't even reach 60 (unless I use vsync). It's probably a problem on my side but I really can't put my finger on it.

[Laurent]

This is the old version (times are in seconds) right?