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

Author Topic: Switched times to Uint32 milliseconds in SFML 2  (Read 20173 times)

0 Members and 1 Guest are viewing this topic.

Tronic

  • Newbie
  • *
  • Posts: 16
    • View Profile
    • http://performous.org/
Switched times to Uint32 milliseconds in SFML 2
« Reply #45 on: December 14, 2011, 03:31:08 am »
Quote from: "OniLink10"
Quote from: "Tronic"
This change is a clear and useless regression.

Use double, keep the API compatibility and keep it precise down to microsecond level for 300 years. Time precision greater than 1 ms is important for various things including audio clock sync, profiling and such. 1 ms jitter is apparent on smooth 60 FPS animation even if not particularly disturbing.

There are highly precise timers available on all major platforms, so there is also no reason to only offer 1 ms precision. Double precision floating-point is lightning fast to calculate with and the extra four bytes for a clock memory footprint cannot be significant either (especially since floats are promoted to double anyway when put into registers or passed to functions).
If you read the arguments FOR using integers in the thread, you would see that that "extra precision" you need wouldn't exist even if floats were used. OSes only guarantee precision to the millisecond level.


As others have pointed out, that belief is bogus. All OSes worth a mention provide nanosecond or similar precision in their time interfaces, and the actual timers on pretty much any platform are of very high precision too. I highly doubt SFML ever getting ported to a system where time precision wouldn't be better than 1 ms.

Also, it needs to be emphasized that double precision float (i.e. double) is needed. Single precision (i.e. float) is not enough as was demonstrated by the original issue that started this thread. Double precision floating-point calculations are extremely fast even on modern mobile platforms (not to mention x86), so the performance won't be an issue. Neither should the 8 byte memory footprint for a time value matter anywhere.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32451
    • View Profile
    • SFML's website
    • Email
Switched times to Uint32 milliseconds in SFML 2
« Reply #46 on: December 14, 2011, 08:57:02 am »
It seems that everybody wants different things:
- nanoseconds, microseconds, milliseconds, seconds
- float, double, Uint32, Uint64

The most flexible approach would be to implement sf::Clock using a Uint64 number of nanoseconds. This is indeed possible on supported OSes; I can even improve the implementation to use only monotonic and non-overflowing functions.

But then I still have to decide what to provide in the public API. I have several solutions, but none of them would satisfy everyone:
- provide Uint64 nanoseconds, but then many people will complain that we're losing the S of SFML
- provide Uint32 milliseconds, but then some people will complain that the resolution is too high
- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)
- provide everything, but then I will complain about the bloated API

If someone can find a clean solution to this problem I'm ready to rewrite sf::Clock again if necessary.
Laurent Gomila - SFML developer

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Switched times to Uint32 milliseconds in SFML 2
« Reply #47 on: December 14, 2011, 03:12:53 pm »
How about some simple-to-use flexible TimeSpan class?

Code: [Select]

class TimeSpan {
   //Whatever;
public:
  //constructors come here

  Uint64 GetNanoseconds() const;
  Uint32 GetMilliseconds() const;
  double GetSeconds() const;
};

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32451
    • View Profile
    • SFML's website
    • Email
Switched times to Uint32 milliseconds in SFML 2
« Reply #48 on: December 14, 2011, 03:25:19 pm »
Quote
How about some simple-to-use flexible TimeSpan class?

It doesn't solve points 3 and 4
Quote
- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)
- provide everything, but then I will complain about the bloated API

And I don't know if it's clear enough that every function returns the same thing with a different type/resolution, it could be a decomposition of a time value instead, like the "tm" struct in time.h.
Laurent Gomila - SFML developer

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Switched times to Uint32 milliseconds in SFML 2
« Reply #49 on: December 14, 2011, 04:14:20 pm »
To be honest, I'm perfectly fine with the current SFML 2 time API.

Laugilus

  • Newbie
  • *
  • Posts: 9
    • View Profile
Switched times to Uint32 milliseconds in SFML 2
« Reply #50 on: December 15, 2011, 01:21:38 pm »
What about :

Code: [Select]
template <class T = Uint32>
class Clock;

template <>
class Clock<Uint32> {/* milisec implementation */};

template <>
class Clock<Uint64> {/* nanosec implementation */};

template <>
class Clock<double> {/* double implementation */};

// A float implementation ???
template <>
class Clock<float> {/* float implementation */};


If every implementation shares the same API, you won't "complain about the bloated API".

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6226
  • Thor Developer
    • View Profile
    • Bromeon
Switched times to Uint32 milliseconds in SFML 2
« Reply #51 on: December 16, 2011, 10:59:50 pm »
The sf::Clock class is only one side of the medal. All the interfaces that work with times have to be adapted, too -- for example, sf::Sleep(), sf::RenderWindow::GetFrameTime() or sf::TcpSocket::Connect().

And if Laurent is against a TimeSpan class with its conversions, the candidates are float seconds (like in early SFML 2) or unsigned int milliseconds (like now). Are there interfaces for which float is too unprecise in real life situations? Or did the change to milliseconds mainly happen to allow long time measuring with sf::Clock?

In this case, an option might entail offering two sf::Clock methods. One for daily wark with the practical seconds, and one for rare high-resolution measuring.
Code: [Select]
float      GetElapsedSeconds();      // or just GetElapsedTime()
sf::Uint64 GetElapsedNanoSeconds();
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Switched times to Uint32 milliseconds in SFML 2
« Reply #52 on: December 16, 2011, 11:49:34 pm »
Quote
Are there interfaces for which float is too unprecise in real life situations?


That question has already been answered.

Quote
Yes, the problem is that they become less accurate too quickly (apparently it becomes a problem after 2.33 hours).

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6226
  • Thor Developer
    • View Profile
    • Bromeon
Switched times to Uint32 milliseconds in SFML 2
« Reply #53 on: December 16, 2011, 11:55:12 pm »
No, it has not. I explicitely asked for real life situations, because no one will call sf::Sleep() with 2.33 hours. So, at which places in the SFML API apart from sf::Clock itself is the inaccurateness an issue?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development: first SFML book

kolofsson

  • Full Member
  • ***
  • Posts: 100
    • View Profile
Switched times to Uint32 milliseconds in SFML 2
« Reply #54 on: December 17, 2011, 09:08:15 am »
Yes, I think that if we care about the "Simple" in SFML, then the time unit should be 1 second, thus forcing to use a floating point variable. With a millisecond as a unit, if you want to keep all your variables true to the SI units, each time you have to divide the time by 1000.

TomCatFort

  • Newbie
  • *
  • Posts: 10
    • View Profile
    • http://tomcatfort.net
Switched times to Uint32 milliseconds in SFML 2
« Reply #55 on: December 18, 2011, 05:44:56 pm »
Quote from: "Laurent"

- provide double seconds, but then some people will complain about the lack of exact timestamps, as well as the need to cast to float every calculation involving time (everything gets promoted to double when one of the operands is a double, but SFML uses float everywhere else)

Casting a floating point type to an another one works by loading the data into one of the FPU registers then unloading it into the target type, this takes a little time yes. But if you do calculations they are loaded in those registers anyway and they are stored in the internal format of the FPU (As I know in Intel processor these registers use 80 bit extended precision) so the most drawback of doubles comes from the double memory usage.

I would personally use unsigned 64 bit integer with nanoseconds so SFML can use the best available timer on the platform. It can be simply converted to milliseconds or the desired floating point value if the programmer want something else.

A TimeSpan class could be made that internally use nanoseconds and provides methods to retrieve it in various other formats. The programmer doesn't even need to carry this class around, they just extract the needed value and propagate that in they code.
Code: [Select]

TimeSpan ts = foo.EllapsedTime();
double deltaTime = ts.AsDoubleSecunds();
update(deltaTime);
render(deltaTime);

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32451
    • View Profile
    • SFML's website
    • Email
Switched times to Uint32 milliseconds in SFML 2
« Reply #56 on: December 18, 2011, 06:00:44 pm »
Quote
the most drawback of doubles comes from the double memory usage

I was talking about the required static_cast, which makes the code verbose and ugly. I don't really care about memory or CPU usage ;)

Quote
I would personally use unsigned 64 bit integer with nanoseconds so SFML can use the best available timer on the platform. It can be simply converted to milliseconds or the desired floating point value if the programmer want something else.

I was thinking about something similar, yes. Except that I'd use microseconds, nobody needs nanoseconds.

Quote
A TimeSpan class could be made that internally use nanoseconds and provides methods to retrieve it in various other formats. The programmer doesn't even need to carry this class around, they just extract the needed value and propagate that in they code.

That's more or less what I'm investigating.
Laurent Gomila - SFML developer

TomCatFort

  • Newbie
  • *
  • Posts: 10
    • View Profile
    • http://tomcatfort.net
Switched times to Uint32 milliseconds in SFML 2
« Reply #57 on: December 18, 2011, 06:03:22 pm »
Quickly wrote a test in java to see how good is the time precision using nanoseconds:
Code: [Select]

final int C = 10;
long[] res = new long[C];
int i = 0;
long tp = System.nanoTime();
while (i < C)
{
    long tn = System.nanoTime();
    if (tn != tp)
    {
        long d = tn - tp;
        tp = tn;
        res[i] = tn;
        i++;
    }
}

for (i = 0; i < C; i++)
    System.out.println(Integer.toString(i) + " = " + res[i]);


This is the result:
Code: [Select]

0 = 181327039326786
1 = 181327039328598
2 = 181327039329503
3 = 181327039330409
4 = 181327039331315
5 = 181327039332221
6 = 181327039332674
7 = 181327039333580
8 = 181327039334485
9 = 181327039335391


It seems that my ordinary laptop can produce far better (although not true nanotime) precision than milliseconds. It is hard to say no to this (personally).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32451
    • View Profile
    • SFML's website
    • Email
Switched times to Uint32 milliseconds in SFML 2
« Reply #58 on: December 18, 2011, 06:08:25 pm »
Yeah yeah, I already said that I agree for sub-millisecond precision (but microsecond is enough) ;)
Laurent Gomila - SFML developer

TomCatFort

  • Newbie
  • *
  • Posts: 10
    • View Profile
    • http://tomcatfort.net
Switched times to Uint32 milliseconds in SFML 2
« Reply #59 on: December 19, 2011, 05:40:58 pm »
Well micro is still a thousand times better then milis! :D

 

anything