Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()  (Read 5027 times)

0 Members and 1 Guest are viewing this topic.

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Why - because it might be super convenient at times.

Often I want to time something by just printfing some time stamps to console/file and look manually at the difference and now it requires me to stick a const sf::Clock somewhere (global) and call getElapsedTime().

Like come on... priv::ClockImpl::getCurrentTime() even already returns sf::Time.

It'd also make classes like stop watches (like the one in Thor) more idiomatic (IMO) by storing start and stop times, not an sf::Clock to use for literally that as well.

sf::Clock being made redundant by this is totally fine by me. There's many components already that are not wrappers over anything OS/library provided but are 'pure' SFML/C++ stuff made for convenience that power users don't use and that many other low level libraries don't provide (like shapes, sprites, text, unicode string conversions, etc.).
Back to C++ gamedev with SFML in May 2023

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()
« Reply #1 on: October 09, 2018, 01:12:46 pm »
The problem with such a function is that we only know that it returns a time. We don't know it's reference. So it is only suitable for measuring delta times. Which is fine, but...

sf::Time getCurrentTime()
{
    static sf::Clock clock;
    return clock.getElapsedTime();
}

... is doable with the current API and makes it clearer what the time reference is.
Laurent Gomila - SFML developer

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()
« Reply #2 on: October 09, 2018, 08:50:08 pm »
We know it's monotonic so it's good for deltas which is what I wanted anyway.

This function with static sf::Clock also has a weird 'reference', first call will be 0 or very close to 0, and the clock starts from then on. It's also only good for deltas unless you call it as soon as you enter the program to make it a 'program running' clock (which has other problems).

And it's silly and cumbersome (I now either need to write it when I want a quick two printfs somewhere or keep it in some header I use) to get what I want by wrapping a class which wraps what I want internally, all just because that one function isn't exposed.

And it relies on sf::Clock not causing problems by being a static local (which it doesn't but other/GL classes will so suddenly if you want it you need to know what's okay to break the "don't make SFML classes static/global" rule with and what isn't).
Back to C++ gamedev with SFML in May 2023

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()
« Reply #3 on: October 09, 2018, 09:07:49 pm »
Quote
We know it's monotonic so it's good for deltas which is what I wanted anyway.
Yes, that what I said, it's good for deltas.

Quote
This function with static sf::Clock also has a weird 'reference'
This is just an example, the good thing with user written code is that you can decide what you do. For example, you could write a "timeElapsedSinceAppStartup" function if you needed to. And in any case, it's not as weird as being OS-dependant, undocumented and potentially different in future versions of SFML.

Quote
It's also only good for deltas
Yes, since that's what you wanted. But you wrote it, so the constraints on it (documentation, consistent behaviour, etc.) are a lot relaxed compared to the same thing put in a middleware.

Quote
And it's silly and cumbersome
You want to measure delta times, which is exactly what sf::Clock does. I don't think it's silly or cumbersome.

Quote
I now either need to write it when I want a quick two printfs somewhere or keep it in some header I use
So as many useful things ;)

Quote
And it relies on sf::Clock not causing problems by being a static local (which it doesn't but other/GL classes will so suddenly if you want it you need to know what's okay to break the "don't make SFML classes static/global" rule with and what isn't).
It's not constructed before main(), unless you call that function to initialize a global variable. So that rule doesn't apply here.
Laurent Gomila - SFML developer

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Expose priv::ClockImpl::getCurrentTime() as sf::Time::getCurrentTime()
« Reply #4 on: October 09, 2018, 09:12:37 pm »
Ok. Well, I tried. :P
Back to C++ gamedev with SFML in May 2023

 

anything