sf::Clock Improvement

[Nexus]

Hi
What do you think about some more features to the sf::Clock class?
For example a function which could pause the timer would be useful. Setting the time to a given float parameter might be of advantage, too.

I think adding a Pause() and SetTime(float Time) function shouldn't be a big problem - or does it upset the whole system because you can't just take the difference between starting and current time anymore?.

[SirJulio]

Hi Nexus,

as you said, sf::Clock is a ... Clock. =p

You don't have to pause a clock, just ask it elpased time. (maybe a stopwatch, and i'm sure, you could easily do that with an encapsulated Clock).

So, IMO, Clock doesn't need this kind of feat. =)

[Laurent]

Other users already wrote such class, you may find some code on the forum (maybe the french one).

[Nexus]

Ok, the problem is, to write an own clock/stopwatch class I can't use the existing sf::Clock since the member myStartTime is private. I should always use GetElapsedTime()... Isn't that a little bit waste of performance?

But in the french forum, I found some propositions...
Thank you!

[Laurent]

Ok, the problem is, to write an own clock/stopwatch class I can't use the existing sf::Clock since the member myStartTime is private. I should always use GetElapsedTime()... Isn't that a little bit waste of performance?

If you think calling a function will waste performances... then never look inside SFML source code, there are tons of them

[Nexus]

Hehe, ok... But SFML is still quite fast
And besides, algorithms like the Clock functions should not be very time-critical... I think, for example graphic rendering requires a lot more performance, doesn't it?

[Laurent]

And besides, algorithms like the Clock functions should not be very time-critical... I think, for example graphic rendering requires a lot more performance, doesn't it?

Absolutely

[workmad3]

Always use the getters and setters provided... if you find they are a performance drain then we should bug Laurent to change them to inline functions instead Data members should stay private so that we can't mess around with SFML's private data and possibly break the clock

[MadMartin]

I'll just pick this thread up:

What's about adding a (static) method to sf::Clock which provides the current system time? Would that make sense? Are there other developers who would appreciate it?

There would be many possibilities for use, e.g. in logging, displaying current time in GUIs, add to savegames for easy identify, e.t.c...

So, Laurent, any comments? :wink:

greetings
Martin

[Laurent]

For most of your examples, using the application time (a global sf::Clock) is enough. System time usually doesn't mean anything, I guess what you request is the current date and time. There are plenty of good and complete libraries which provide that, like boost.date_time or any GUI library (Qt, wxWidgets, MFC, ...).

[Nexus]

The standard header <ctime> provides some useful time functions, too.

[MadMartin]

Ah, yes, Boost. Should've thought about that :!:

@Nexus:
No, no ctime
I don't like it to mix C and C++, I'm trying to stick to as clean as possible C++  :wink:

BTW: Bist du der Nexus, der im Forum von c-plusplus.de unterwegs ist?

[Nexus]

BTW: Bist du der Nexus, der im Forum von c-plusplus.de unterwegs ist?

Genau der

[zarka]

Always use the getters and setters provided... if you find they are a performance drain then we should bug Laurent to change them to inline functions instead Data members should stay private so that we can't mess around with SFML's private data and possibly break the clock

the compiler is usualy smart enough to make simple getters and setters inline anyway so ther should be no worries