SFML community forums
Help => Graphics => Topic started by: Contadotempo on May 25, 2011, 08:59:44 pm
-
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.
-
Now sf::Window::GetFrameTime returns milliseconds as sf::Uint32 (see the doc (http://www.sfml-dev.org/documentation/2.0/classsf_1_1Window.php#a81164bb845cd6ccc6c8ac981bca44ac4))
-
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?
-
Nop, but v-sync can be forced off in the graphics driver.
-
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:
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.
-
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.
-
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 :)
-
Everything's explained in the dedicated topic on the General forum ;)
-
Whoops, I'm sorry as I didn't notice there was already a topic for it.
Thanks for all the help.
-
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.
-
Can you try with the revision *before* the one that changed times to Uint32?
-
Yes, I recompiled the commit from 2011-05-15 (https://github.com/SFML/SFML/commit/6383f0c8000eb34ee59af74ce5bfd319722f3f56) and it seems to limit the frames to exact 60 again (Confirmed with FRAPS).
-
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.
-
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.
(http://img837.imageshack.us/img837/672/semttulodf.png)
-
This is the old version (times are in seconds) right?
-
Ah yes sorry. Its the one just before the time update.
-
So there was already a problem before the update.
-
I think this is very confusing so I'll summarize all I've done so far:
1- I had an old SFML 2.0 revision compiled (the one when GetEvent() was changed to PollEvent(), everything was working top notch).
2- The day I made this topic, I updated it to the revision where times were changed to uint32. This didn't allow me to maintain 60 FPS with SetFramerateLimit(60) as I would get 66 ~ 67 FPS.
3- Last night I've downgraded to the revision before times change and SetFramerateLimit(60) worked well again.
4- Today, I'm not even able to reach 60 FPS, unless I enable VerticalSync, as seen in the image: [LINK] (http://img837.imageshack.us/img837/672/semttulodf.png) (using the revision before times update).
What might the problem be? Maybe I could try downgrading even further.
-
And today I'm able to reach 60 FPS again (with the same commit, same source code). I don't get this. One day it works, the other doesn't.
At least now I'm almost sure this isn't a bug in SFML and it's most likely my graphic's driver acting up (ATI) so I won't bother anyone anymore. Thanks for all the help!
PS: May I leave with just one request? I know SFML 2.0 still isn't ready so I don't really have the right to make any requests but...
Laurent, could you possibly in the future add the choice for the user to choose between general time in milliseconds or seconds? In the thread "Best practices concerning time handling" (http://www.sfml-dev.org/forum/viewtopic.php?t=4910) Nexus mentioned the following and I agree:
Seconds are easier to imagine.
Excuse my poor English.
Regards :)
-
May I leave with just one request? I know SFML 2.0 still isn't ready so I don't really have the right to make any requests but...
You must make requests before SFML 2.0 is released, because if it requires breaking the API, I won't be able to implement it after the public release (and you'll have to wait for SFML 3) ;)
Laurent, could you possibly in the future add the choice for the user to choose between general time in milliseconds or seconds?
How could I do that?
-
How could I do that?
Changing all Uint32 to Time, a wrapper class that has getMillisec : Uint32 and getSec : float :?:
Anyway, it seems a little bit useless to me because the conversion is kind of easy and can be done via a simple function.
-
Changing all Uint32 to Time, a wrapper class that has getMillisec : Uint32 and getSec : float :?:
The idea is good, but as you see in the linked thread, such a class also has some disadvantages ;)
-
Right! I just skim through the topic and your points stands.
-
Anyway, it seems a little bit useless to me because the conversion is kind of easy and can be done via a simple function.
I guess I have to agree but I find myself always converting everything to seconds as I haven't found a use for milliseconds yet, especially in physics and clocks as I have more ease recreating situations in seconds (and I'm not that great at maths).
By the way I'm doing ( (Time in sf::uint32) / 1000.f) to convert it to seconds. Is this the best practice? Using a floats to preform operations on sf:uints I mean.
-
I guess I have to agree but I find myself always converting everything to seconds as I haven't found a use for milliseconds yet, especially in physics and clocks as I have more ease recreating situations in seconds (and I'm not that great at maths).
That's unfortunately also how I see it :(
The problem with float was the precision at sf::Clock for long times. As I see it, other times like sf::Window::GetFrameTime() don't have this issue. And I think double might have been easier to handle, while still precise enough.
By the way I'm doing ( (Time in sf::uint32) / 1000.f) to convert it to seconds. Is this the best practice? Using a float to divide I mean.
You can also write a function, but it has only limited advantage (a little bit more expressive than the division). Otherwise, I think the denominator type depends on the context it is used in: If you have a function that takes a double, divide by 1000.; for long doubles, divide by 1000.l.
Another option is a Time class like discussed in the other topic. But since SFML doesn't use it for times, you still have to convert almost everything. A
Time(clock.GetElapsedTime()).ToSeconds()is even uglier than
clock.GetElapsedTime() / 1000.f