Switched times to Uint32 milliseconds in SFML 2

[Groogy]

50 days of insignificantly less accurate instead of approx 2 hours of insignificantly more accurate? Sounds good to me!

Ha, you never played WOW, EVERCRACK, or BC2 Sleep what's that?

I used to play WoW. Never got addicted. Never saw what was addicting about it. In fact, it bored me.
Your point is?

^--- What he said
EVE though on the other hand.. If I could inject it, I would...

[Mars_999]

50 days of insignificantly less accurate instead of approx 2 hours of insignificantly more accurate? Sounds good to me!

Ha, you never played WOW, EVERCRACK, or BC2 Sleep what's that?

I used to play WoW. Never got addicted. Never saw what was addicting about it. In fact, it bored me.
Your point is?

My point is you are apparently not one of 11+million users who are. So you aren't the norm.

Either way the main point is some games run more than a day I seen some friends who let their computers sit there and run as there was no save function vs. going through the game again, and it sat there for days....

OH BTW I have not played WOW, EVERCRACK, but BC2 ahhhh yes good times!

Couldn't we just overload the function? And keep the float version also? Not sure what harm that would do....

[Nexus]

Couldn't we just overload the function? And keep the float version also?

You cannot overload functions if their signature (name and parameters) is the same. At sf::Clock::GetElapsedTime(), only the return value was changed, not the signature.

The only option would be a function with another name, for example GetElapsedSeconds() and GetElapsedMilliseconds().

[Mars_999]

Couldn't we just overload the function? And keep the float version also?

You cannot overload functions if their signature (name and parameters) is the same. At sf::Clock::GetElapsedTime(), only the return value was changed, not the signature.

The only option would be a function with another name, for example GetElapsedSeconds() and GetElapsedMilliseconds().

My bad for not looking at the function ahead of time. I assumed we sent in a parameter... How about a template class then....

[Laurent]

My bad for not looking at the function ahead of time. I assumed we sent in a parameter... How about a template class then....

No way. sf::Clock is a very simple class, its interface must remain simple.
But I don't understand your point: float allows even less precision (2.33 hours vs 50 days for uint32). The only way to allow more would be to use uint64.

[Kian]

The beauty of ints is you just concatenate them together, and get a bigger int.

It's only fifty days if you don't check for an overflow. If you expect the timer to have to go longer than 50 days, you can make a quick check to see if the new time is greater than the old time. If it isn't, add one to another int. This new int holds the number of times you overflowed. Multiply by fifty, and you got the whole length of days. For a regular 32 bit int, this method gives you millisecond precision out to... 18,446,744,073,709,551,615ms, which works out to 584,542,046 years.

Half a billion years should be enough for most purposes. Add another counter in case you overflow this one, and it should provide room for longer than the age of the universe.

[Svenstaro]

Or just use uint64_t to begin with.

[Disch]

I'm not sure what the issue is here... maybe I didn't read the thread correctly.

I 100% agree with the change to Uint32.  In fact before it existed I had to have a wrapper class around sf::Clock to convert the times to Uint32.

The big problem with floats is that the higher they get, the less precise they are.  As was mentioned, after about 2 hours, a float timer will begin to lose precision.  2 hours is nothing for a game -- many people play games for several hours at a time.

Other non-game programs are sometimes run 24/7.  In that instance a float clock would be near worthless.

With Uint32 you don't ever have to worry about loss of precision.  You have millisecond precision (give or take depending on the platform) and it's consistent.

If you want a float clock, it's easy to wrap the Uint32 version to produce a float  (return Time() / 1000f;).  The opposite is not true because the loss of precision can skew the timing and give you false results.  The only way I could accomplish it in my attempts was to reset the clock every now and then to ensure there was no loss of precision.  However this has side effects of adding possible gaps in the time, and the clock requiring occasional CPU attention.

[Laurent]

Or just use uint64_t to begin with.

That wouldn't prevent the returned Uint32 from overflowing.

[pdinklag]

Couldn't we just overload the function? And keep the float version also? Not sure what harm that would do....

The float version is obsolete really. The simple conversion from Uint32 milliseconds to float seconds comes for free basically and allows for the highest possible precision.

Using a 32-bit field for a time stamp is becoming really uncommon these days, though. There shouldn't be too much of a problem since the counting begins with the initialization of the clock, but I'd still suggest going with the flow and using a 64-bit value here.

Since overloading isn't possible with the same signature, I'd suggest to simply change the return time of GetElapsedTime to Uint64. That will require people to change their code again, but SFML2 isn't yet official and this hassle wouldn't have to be bothered with anymore in the future (at least not the foreseeable future).

Another possibility would be adding a function like "GetElapsedTimeLong" that returns a Uint64. The clock's internal counter would be a Uint64 value and the old Uint32 version would simply return the lower 32 bits. It would keep people from having to alter their sources again, but IMO going to Uint64 entirely is the best way.

[Nexus]

The float version is obsolete really. The simple conversion from Uint32 milliseconds to float seconds comes for free basically

The conversion is still explicitly necessary; forgetting it may lead to warnings, while the code still compiles. But it is of course possible. My point is, the same code is now more complicated on user side, either because

• One has to work with the less imaginable milliseconds or
• There is the omnipresent /1000.f to get seconds or
• External wrapper functions or classes are necessary to get seconds in a simple way.

There shouldn't be too much of a problem since the counting begins with the initialization of the clock, but I'd still suggest going with the flow and using a 64-bit value here.

I don't think a 64 bit type brings relevant advantages. To "go with the flow", Laurent should take std::time_t and not an arbitrary integer type. But in my opinion, sf::Uint32 is fine for milliseconds.

[Laurent]

I don't think that time_t is a good candidate:

ISO C defines time_t as an arithmetic type, but does not specify any particular type, range, resolution, or encoding for it. Also unspecified are the meanings of arithmetic operations applied to time values.

Unix and POSIX-compliant systems implement time_t as an integer or real-floating type [1] (typically a 32- or 64-bit integer) which represents the number of seconds since the start of the Unix epoch: midnight UTC of January 1, 1970 (not counting leap seconds).

And I don't think it's worth using Uint64, people often end up storing time in Uint32, therefore they would need explicit static_cast so that the compiler doesn't complain about potential loss of precision.

[pdinklag]

There is the omnipresent /1000.f to get seconds or

Isn't that what macros were invented for? (which I don't have in Java )

[Disch]

Isn't that what macros were invented for?

Ugh, no.  Macros violate scope rules and pollute the namespace.

an inline function or a wrapper class would be better:

Code: [Select]


// to keep this simple, it does not handle wrapping gracefully
//   do not run for more than 49 days
//   (although because it gives you a float, it will become useless earlier
//    than that anyway)
class ClockFloat
{
  sf::Clock clk;
public:
  inline void Reset()
  {
    clk.Reset();
  }

  inline float GetElapsedTime()
  {
    return clk.GetElapsedTime() / 1000.0f;
  }
};


[Haikarainen]

Umm, just a sidenote: Couldn't the 50-dayslimit of uint32 be a lot larger if you we're to use a multiplier int on the side?
Like when the uint32 has reached its limit, the multiplier +=1, and the uint resets. And then just get the time using `(maxvalue of a uint32 * multiplier int) + current uint32 value ? Or would that cause trouble to precision?

Edit; was that really stupid or is there some sort of precise type that can store such high values as a returntype?