Switched times to Uint32 milliseconds in SFML 2

[Laurent]

There's Uint64 but I don't want to use it. I'm fine with Uint32 and its 49.7 days limit.

[Tronic]

This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).

[kolofsson]

Sorry to resurrect this thread but I've got a question.

Let's assume that each one frame of some game lasts a constant 1.6 ms. By one frame I mean one loop cycle. The question is: what will be the elapsed time value? Will it be equal to 2 ms each frame?

I'm asking because the elapsed time is used to calculate movement of an object by multiplying its velocity by the elapsed time. When the interval is big, there is no problem, but if it is as small as I've suggested, will there be problems?

I must say I'm not convinced to using integer for storing time. It's like limiting sprite position to full pixels.

[Laurent]

There will be a problem indeed, since 1.6 can't be returned (it will be 1 by the way, C++ truncates when it converts float to int).

[gsaurus]

I'm experiencing a problem that may be related to this. I'm using a clock in the game loop to monitor the time taken by logics updates and by draws, so if updates take too long, the display is skipped, if everything is done quickly I make it sleep the rest of the frame duration, and things like that, so every frame has exactly the same duration. But the clock introduces errors, specially if updates or draws are fast, and I need precision because of netplay synchronization.

When I drag/resize the window it desynchronizes a little bit more (game goes a little bit faster than expected), I'm not sure how the integer timer is affecting it or not, maybe I have something wrong anyway.

[OniLinkPlus]

This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).

If you read the arguments FOR using integers in the thread, you would see that that "extra precision" you need wouldn't exist even if floats were used. OSes only guarantee precision to the millisecond level.

[Felheart]

It's a bit unclear to me but if I set the fps limit to 100:
window.SetFramerateLimit(100);
then, i accumulate the the value of GetFrameTime(); each frame.
After exactly one day, will my "accumulated-time" variable differ significantly from the value "86400000" (milliseconds in a day) ??

In other words, will GetFrameTime try to make up for previous errors / inaccurate measures?

I am currently using my own timing system (I use the .NET bindings and the Stopwatch class) in order to minimize such errors.

[kolofsson]

There will be a problem indeed, since 1.6 can't be returned (it will be 1 by the way, C++ truncates when it converts float to int).

What if my loop lasted shorter than 1 ms (0.9 ms), would it be truncated to 0 ms?

Also, if I ran a loop that would accumulate the elapsed time, the loop lasting 1,9 ms (displayed as 1 ms), after 1000 frames 1,9 second would have elapsed in reality, but the accumulated timer value would show 1 second! That's seriously crappy. In that case I would totally drop the frame timer and go for a global timer. Then the differences would be corrected, right?

What do you mean that OS guarantees 1ms as the smallest measurement? If so, then why was the float displaying non-round FPS values, like 1700 FPS?

[Laurent]

will GetFrameTime try to make up for previous errors / inaccurate measures?

No.

What if my loop lasted shorter than 1 ms (0.9 ms), would it be truncated to 0 ms?

Yes.

In that case I would totally drop the frame timer and go for a global timer. Then the differences would be corrected, right?

Yes.

What do you mean that OS guarantees 1ms as the smallest measurement? If so, then why was the float displaying non-round FPS values, like 1700 FPS?

Indeed it's not true, all OSes can provide sub-millisecond resolution.

[gsaurus]

What if my loop lasted shorter than 1 ms (0.9 ms), would it be truncated to 0 ms?

This is most likely what is happening with my game, specially during window drag/resize when display is ignored, truncations make my game run a little bit faster . Any suggestion?
I see two different uses of clocks: longterm and precision measurements, sometimes I wish there were one clock for each.

[kolofsson]

This is most likely what is happening with my game, specially during window drag/resize when display is ignored, truncations make my game run a little bit faster . Any suggestion?
I see two different uses of clocks: longterm and precision measurements, sometimes I wish there were one clock for each.

Yes we could have a float precision clock, what's the problem, what's the harm?

Gsaurus, I guess a global timer would help you. Then, each frame you could store the timestamp in an array:

Code: [Select]

timestamp[frame_number] = gettime()

And then, to get the time elapsed:

Code: [Select]

time_elapsed = timestamp[current_frame] - timestamp[current_frame - 1]

if time_elapsed equals 0, skip this iteration of the loop.

[Nexus]

In the long term, a high precision clock might indeed be useful. Actually, I personally find milliseconds quite annoying -- they are too unprecise for some measurements, and very cumbersome for everyday work (seconds are usually easier to imagine and to work with)

I also thought about writing high precision clocks on top of SFML, but given its current interface, I have to duplicate the whole code (i.e. sf::Clock and the implementation for all platforms), if I'm not mistaken. If at least sf::priv::GetSystemTime() returned nanoseconds, I could use it as a workaround for the time being

[kolofsson]

milliseconds  are too unprecise for some measurements, and very cumbersome for everyday work (seconds are usually easier to imagine and to work with)

Exactly! If I'm using the standard SI physical units and want to calculate car/ball movement in a single frame, I have to multiply velocity (meters/second) * delta time (milliseconds) and divide it by 1000. This is really neither fast nor elegant.

EDIT: Since I'm using Python (and still learning it), I found a neat function in Python called time.clock(). The description from the docs: a floating point number, based on the Win32 function QueryPerformanceCounter(). The resolution is typically better than one microsecond.


I guess, bye bye sf::timer

[Spidyy]

I kept the old version of sf::clock (in millisecond) because it is really more easy to use. No need for additionnal conversion or reflexion. I don't use the network so I don't need precisely timed clock, and having to do some tricks to have a decent FPS counter or whatever don't have its place in the S of SFML.

BTW, the clock mechanism are easy to change or use. And the wiki exist.

[Nexus]

BTW, the clock mechanism are easy to change or use. And the wiki exist.

Yes, but changing SFML itself is not a good idea, I prefer non-intrusive approaches. And as mentioned, you currently need to duplicate the whole SFML code if you want to measure microseconds in a platform-independent way.