Switched times to Uint32 milliseconds in SFML 2

[Laurent]

Hi

A major API break today: I changed all times to be Uint32 number of milliseconds instead of float number of seconds.

It may potentially break a lot of code, so... good luck for updating :mrgreen:

Here is a list of what is modified by this update:
- sf::Clock::GetElapsedTime
- sf::Window/RenderWindow::GetFrameTime
- sf::SoundBuffer/Music::GetDuration
- sf::SoundStream/Sound/Music::Set/GetPlayingOffset
- sf::SoundStream::OnSeek
- timeouts in sf::Http/Ftp/TcpSocket/IpAddress/SocketSelector

As a bonus, I also added the sf::Int64 and sf::Uint64 types.

[xazax]

Yay!

Good news for me, most of us (at least I think) is more comfortable with the milliseconds, since most of the libraries use that approach.

Thanks!

[Tank]

Very good.

[Nexus]

Oh, so I already know what to do next in Thor

I think the client code of RenderWindow::GetFrameTime() becomes more complicated when game logic functions work with a float dt (part of a second). However it would be inconsistent not to change it as the single function in SFML. Another option would is also to modify the logic ticks where possible and only work with milliseconds.

It's a good thing that you get rid of float's inaccuracy for long times. But aren't the floats theoretically more precise than a millisecond? As far as I know, QueryPerformanceCounter on Windows may have a higher resolution than 1 ms.

The addition of the 64 bit types is very nice!

[Laurent]

Just out of interest: Weren't the floats theoretically more precise than a millisecond? On the counterpart, they are less accurate for long times.

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

[Nexus]

So you sacrifice the high-performance timers for the sake of long measurements, which are of course more realistic. You could have had both advantages with double, couldn't you?

[Laurent]

So you sacrifice the high-performance timers

Nop, SFML never claimed to support less than 1 ms precision. The reason why floats were initially used is not the extra precision they can store.

You could have had both advantages with double, couldn't you?

In fact I decided to stop using floating point numbers in general, and switch to types that allow exact representations -- integers.
And it makes little sense to go below millisecond precision, it's hard to achieve and rarely needed. So Uint32 is enough.

[Disch]

This is great news!

[Nexus]

Okay, that makes sense, thanks for the explanation! I'll have to work a little with the new units until I fully see their advantages and limits.

By the way, I don't think an additional #ifdef _MSC_VER is necessary for the 64 bit types, because MSVC++ supports signed/unsigned long long since 2005. See here

[Laurent]

By the way, I don't think an additional #ifdef _MSC_VER is necessary for the 64 bit types, because MSVC++ supports signed/unsigned long long since 2005

Oh ok, but I think it's safer to leave it -- although I officially don't care about VC6, VC2002/2003 are still supposed to work

[Svenstaro]

So with uint32 we will get problems only after almost 50 days. Good enough for me and about any purpose I can think of where sfml would be utilized.

[OniLinkPlus]

50 days of insignificantly less accurate instead of approx 2 hours of insignificantly more accurate? Sounds good to me!

[Tank]

Not less accurate, but overflowing. There's the time when all 32 bits are 1.

[Mars_999]

50 days of insignificantly less accurate instead of approx 2 hours of insignificantly more accurate? Sounds good to me!

Ha, you never played WOW, EVERCRACK, or BC2 Sleep what's that?

[OniLinkPlus]

50 days of insignificantly less accurate instead of approx 2 hours of insignificantly more accurate? Sounds good to me!

Ha, you never played WOW, EVERCRACK, or BC2 Sleep what's that?

I used to play WoW. Never got addicted. Never saw what was addicting about it. In fact, it bored me.
Your point is?