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

Author Topic: sf::Time & sf::Clock vs C++11 chrono  (Read 31721 times)

0 Members and 2 Guests are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11030
    • View Profile
    • development blog
    • Email
sf::Time & sf::Clock vs C++11 chrono
« on: March 08, 2017, 12:58:37 pm »
Info & Rules about this sub-forum

With C++11 we finally got access to <chrono> a native and thus cross-platform C++ standard library timing and clock functionalities.

SFML 2.x and earlier has introduced its own sf::Clock and later sf::Time classes to deal with time dependent functionalities internally but also as library features, useful in pretty much any application.

Questions are now:
  • Should we completely drop sf::Time and sf::Clock?
  • Or should we keep the classes but internally use <chrono>?
  • What are your arguments for either situation?
  • Do you have any concerns about <chrono>?
For comparison here are two simple clock example as one can probably find in many games. Let us know if you think there are better examples/implementations to show the API differences.

(click to show/hide)

(click to show/hide)


Summary
  • Keep sf::Time
    • Internally use std::chrono::nanoseconds
    • Add conversion from and to std::chrono::duration
  • Make sf::Clock a stopwatch
« Last Edit: March 14, 2017, 01:42:51 am by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jonny

  • Full Member
  • ***
  • Posts: 114
    • View Profile
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #1 on: March 08, 2017, 02:17:31 pm »
chrono functionality with SFML interface would be ideal ;)

I like the power/flexibility of chrono, but it can often be quite verbose and lacks simplicity for common tasks. If I had to choose I'd say remove the SFML classes (ultimately it's one less thing to maintain and allows development to focus on other new features).

Mario

  • Moderator
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #2 on: March 08, 2017, 02:27:23 pm »
I'd vote for thin wrappers, i.e. existing SFML class around the standard library stuff. Why? Because of simplicity. It's very unlikely this would cause any significant maintenance overhead, but at the same time it makes usage so much simpler, because SFML's interface is far less elaborate/flexible and hides lots of optional complexity.

<chrono> has a higher entry level/knowledge requirement compared to sf::Clock.

Also keep in mind that nobody is forced to use these classes. if you need more control, e.g. to pick your timer class/accuracy, nobody stops you from using <chrono> directly, but especially from a newbie friendly approach, it's far better to offer a thin wrapper that's both easy to understand and use. Especially considering they're not really "off-topic" for SFML's scope.
« Last Edit: March 08, 2017, 03:01:30 pm by eXpl0it3r »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #3 on: March 08, 2017, 06:21:25 pm »
I usually think it's better to use standard stuff, because it is more flexible, robust, documented, used, etc. and people don't have to learn yet another xyz class which just works for this specific framework. And we can focus on the real value of SFML (multimedia abstractions) rather than thin wrappers provided for pure convenience.

But I have to admit that std::chrono makes things more verbose and confusing than needed... So here is my suggestion:

sf::Time looks much better than the standard equivalent (either verbose templates everywhere, or std::chrono::nanoseconds which looks confusing). So I'd keep it. With additional conversions to and from std::chrono::duration, if possible.

sf::Clock doesn't deserve to exist compared to a standard clock::now() (yes, don't be afraid to typedef those long standard clock types). But it's convenient because it returns that sf::Time that I want to keep in the API. So let's make it more useful! Everyone wants a pausable clock, let's do it. Maybe we can even find other good ideas in the long list of suggestions/implementations available.

PS: here is the standard example using less verbose syntax (let's not make it more complicated than it is ;))

(click to show/hide)
« Last Edit: March 08, 2017, 08:32:49 pm by Laurent »
Laurent Gomila - SFML developer

Lin

  • Newbie
  • *
  • Posts: 6
  • Just another game developer.
    • View Profile
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #4 on: March 09, 2017, 05:51:46 am »
I'd like SFML to keep its own clock wrapper because I use the C binding of SFML, and removal of it would require me to use another library or do an extra step to link <chrono> in my project.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #5 on: March 09, 2017, 06:32:27 am »
Quote
I'd like SFML to keep its own clock wrapper because I use the C binding of SFML
Bindings should not interfere in the design choices for the core libraries. If feature xxx is standard in C++ but not in yyy language, then SFML should not be concerned about it ;)
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #6 on: March 09, 2017, 07:23:39 am »
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #7 on: March 09, 2017, 11:14:31 am »
sf::Time looks much better than the standard equivalent (either verbose templates everywhere, or std::chrono::nanoseconds which looks confusing). So I'd keep it. With additional conversions to and from std::chrono::duration, if possible.

I think it's really important to have something easy to use for the various part of SFML that deal with duration. But providing something specific to SFML also has the downside to make it harder to use with other STL features.

But is the STL version really that verbose or confusing? I mean, its API looks very similar to SFML's. We could simply use an alias in the sf namespace to represent time duration.

(click to show/hide)

Disclaimer: I haven't used this API yet actually, so if I missed something more complex than that, let me know.


By the way, is std::chrono::duration<float> a number of seconds?
Yes, the default ratio for time duration is one, which is expressed in seconds. Also relevant for the curious among us: http://en.cppreference.com/w/cpp/chrono/treat_as_floating_point
SFML / OS X developer

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #8 on: March 09, 2017, 11:23:08 am »
Quote
We could simply use an alias in the sf namespace to represent time duration
I can imagine a few drawbacks:
1. Nothing, in your function that takes a sf::Time, indicates that you work with nanoseconds; in the end you'll constantly go see that typedef to know what sf::Time is
2. You're not showing conversion from sf::Time to something else than nanoseconds; this is where std::chrono is quite verbose
3. "5s" is okay, but what about 3.2 seconds? its creation will be more verbose, and you'll end up with a duration<float> that will no longer be implicitly convertible to sf::Time (you'll have to duration_cast)
Laurent Gomila - SFML developer

Hiura

  • SFML Team
  • Hero Member
  • *****
  • Posts: 4321
    • View Profile
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #9 on: March 09, 2017, 12:26:05 pm »
I see now what you meant! It's indeed not as simple as I initially thought.
SFML / OS X developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #10 on: March 10, 2017, 09:09:12 am »
I completely agree with idea of having sf::Clock, but implementing it with <chrono>.

What if sf::Time just stored time in std::chrono::nanoseconds and had all the same functions like asSeconds(), asMilliseconds() and just used duration_cast in implementations? We may also add some user-defined literals like "s", "ms" and then we'd be able to write:
music.setPlayingOffset(500ms);

sf::Time may also have implicit constructors which accept std::chrono::nanoseconds, std::chrono::milliseconds, std::chrono::seconds so that conversions from standard library things to sf::Time are possible.
« Last Edit: March 10, 2017, 09:11:34 am by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #11 on: March 10, 2017, 09:22:10 am »
Quote
What if sf::Time just stored time in std::chrono::nanoseconds and had all the same functions like asSeconds(), asMilliseconds() and just used duration_cast in implementations?
That was the implicit plan :)

Quote
We may also add some user-defined literals like "s", "ms" and then we'd be able to write
Quote
sf::Time may also have implicit constructors which accept std::chrono::nanoseconds, std::chrono::milliseconds, std::chrono::seconds so that conversions from standard library things to sf::Time are possible
Implicit constructors already allow to write "music.setPlayingOffset(500ms), no need to define our own user-literal suffixes.
Also, we may not need as many constructors. Anything with integer representation and higher period can be implicitly converted to std::chrono::microseconds, and same for a duration<float, seconds>. Or if it doesn't work too well, we can have a single templated constructor and use duration_cast to get microseconds.
Laurent Gomila - SFML developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #12 on: March 10, 2017, 09:28:32 am »
That's good to know, just makes everything simpler for implementation.  ;D
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

MrOnlineCoder

  • Jr. Member
  • **
  • Posts: 87
    • View Profile
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #13 on: March 10, 2017, 08:38:31 pm »
I love sf::Clock more that that chrono, that casts,declartions are not so great as usage of Clock, IMO.  I agree with Mario, Clock is more friendly, I think.

jill

  • Newbie
  • *
  • Posts: 19
    • View Profile
Re: sf::Time & sf::Clock vs C++11 chrono
« Reply #14 on: March 12, 2017, 02:03:25 am »
Both are very great api. I prefer learn both of them. sf::Clock & sf::Time means more sfml-native and more object-oriented. And std::chrono means portable: it can be used not only in sfml, but also many other apis(Saying these words is embarrassed in sfml community ;D), so std::chrono is: learn only once and use anywhere. So,  I prefer learn both.