The new time API

[Laurent]

Hi

Many users complained after I switched to milliseconds for time
http://www.sfml-dev.org/forum/viewtopic.php?t=4864
... this thread clearly shows that people need different resolutions and different types for representing time values.

I could of course provide the most precise (Uint64 nanoseconds) but that would not be simple --  user code would be pretty ugly.

So here is a proposal for a new time API, that is a little more verbose than before but should make everyone happy.

Code: [Select]

class Time
{
public:

    Time();
    float ToSeconds() const;
    Int32 ToMilliseconds() const;
    Int64 ToMicroseconds() const;

private:

    Int64 myMicroseconds;
};

Time Seconds(float amount);
Time Milliseconds(Int32 amount);
Time Microseconds(Int64 amount);

class Clock
{
public:

    Time GetElapsedTime() const;
    ...
}

void Sleep(Time duration);
// same in all functions that require/return a time value
User code:

Code: [Select]

sf::Clock clock;

sf::Time elapsed = clock.GetElapsedTime();
game.Update(elapsed.ToSeconds());

sf::Sleep(sf::Milliseconds(100));
sf::Time would be a time span, not a time point, so negative values would be allowed (hence the signed integers). It would have comparison and mathematical operators.
It could also support implicit conversions to/from std::chrono classes in the future.

[Mario]

Sounds good, although I'd tend to return a const reference to a Time member inside Clock (not sure about Time's structure).

What are the function calls after the class definition for? I'm a bit confused there.

[Klaim]

It would be fine, as far as the internal data is integer type to keep the precision.

[Laurent]

Sounds good, although I'd tend to return a const reference to a Time member inside Clock (not sure about Time's structure).

A time is an integer value, nothing more. But let's focus on the API please, not the details

What are the function calls after the class definition for? I'm a bit confused there.

They construct time values. sf::Time has no constructor other than the default one, one must use one of these three functions.

It would be fine, as far as the internal data is integer type to keep the precision.

Internally it is of course a Int64 number of microseconds.

[Ceylo]

Looks fine to me

[Silvah]

So here is a proposal for a new time API, that is a little more verbose than before but should make everyone happy.

It's almost certain that some people will not like it. You know, "omfg what u done its not simple anymore"

As my opinion goes, it's okay.

[Tex Killer]

Yeah, I knew this would come. Totally endorsed.

[Groogy]

This is very similar to how I implemented time in rimfrost engine. But we also have hierarchy timers. Though think that is over kill here.

Anyway you have my thumbs upp.

[c0ffee]

"omfg what u done its not simple anymore"

[julen26]

It seems nice for me.
This way SFML still keeps satisfaying all of its users  

[hayer]

I don't see any pause? :- (

And a interval with a callback like C# timers would be nice, but I guess I could just convert my old class.

[eXpl0it3r]

Internally it is of course a Int64 number of microseconds.

Okay does that really remove the issue?

I mean you handle time still as Int64 which has the problem that you get 0 for all the function calls in between 0 and 1ms.
Which means that if I had a game loop that executes faster than 1ms I still would have to deal with the problem of 0.
Example: If I add every iteration the float of the passed time I'll constantly add 0+0+0+0+0, maybe occasionally get an 0.000001 in there but looking at my variable it would seem as if time has stopped.

Sure it can be fixed with always forcing to add a least 0.000001 and then sync it from time to time with the exact int and who ever needs performance below 1ms?

Just saying it doesn't fix all the issues...

[Walker]

Looks good to me.

Internally it is of course a Int64 number of microseconds.

Okay does that really remove the issue?

I mean you handle time still as Int64 which has the problem that you get 0 for all the function calls in between 0 and 1ms.
Which means that if I had a game loop that executes faster than 1ms I still would have to deal with the problem of 0.
Example: If I add every iteration the float of the passed time I'll constantly add 0+0+0+0+0, maybe occasionally get an 0.000001 in there but looking at my variable it would seem as if time has stopped.

Sure it can be fixed with always forcing to add a least 0.000001 and then sync it from time to time with the exact int and who ever needs performance below 1ms?

Just saying it doesn't fix all the issues...

Looks like he would be storing microseconds in that int64, not milliseconds.

[Tank]

Seems to be a good solution. And whoever thinks it's not simple anymore... wtf? ;-)

[Hiura]

I don't see any pause? :- (

Pause() in the Time class ? I wouldn't make any sense. As Laurent said :

sf::Time would be a time span

BTW : looks good!