Author Topic: SFML 2.0: GetFrameTime (Read 8819 times)

Contadotempo · « **Reply #15 on:** May 27, 2011, 05:20:29 pm »

Ah yes sorry. Its the one just before the time update.

Laurent · « **Reply #16 on:** May 27, 2011, 06:06:46 pm »

So there was already a problem before the update.

Contadotempo · « **Reply #17 on:** May 27, 2011, 09:47:18 pm »

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] (using the revision before times update).

What might the problem be? Maybe I could try downgrading even further.

Contadotempo · « **Reply #18 on:** May 28, 2011, 10:03:51 pm »

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" Nexus mentioned the following and I agree:

Quote from: "Nexus"

Seconds are easier to imagine.

Excuse my poor English.

Regards

Laurent · « **Reply #19 on:** May 28, 2011, 10:10:07 pm »

Quote

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)

Quote

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?

Hiura · « **Reply #20 on:** May 28, 2011, 11:08:41 pm »

Quote from: "Laurent"

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.

Nexus · « **Reply #21 on:** May 29, 2011, 01:06:39 am »

Quote from: "Hiura"

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

Hiura · « **Reply #22 on:** May 29, 2011, 01:11:46 am »

Right! I just skim through the topic and your points stands.

Contadotempo · « **Reply #23 on:** June 07, 2011, 06:46:58 pm »

Quote from: "Hiura"

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.

Nexus · « **Reply #24 on:** June 07, 2011, 07:24:41 pm »

Quote from: "Contadotempo"

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.

Quote from: "Contadotempo"

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

Code: [Select]

Time(clock.GetElapsedTime()).ToSeconds()is even uglier than

Code: [Select]

clock.GetElapsedTime() / 1000.f