Double Precision

[Laurent]

Please use the "quote" tag, it makes your posts clearer when you quote other people

Sorry what bug?

See this:
http://www.sfml-dev.org/todo/index.php?do=details&task_id=136&project=1&order=category&sort=asc

What's not reliable is a call to sf::Sleep (in case that's what you want to use).

You know when you send a thread to sleep, but you don't know exactly when the OS will make it wake up. Once the OS switches to another thread, it may be busy longer than the amount of ms that you passed to sf::Sleep, this value is only a hint.

I definitely need Sleep to be as precise as it could get.

You should find tutorials about how video players perform time synchronization. In my opinion this is a very specific topic, and it may require more complex things than Sleep().

I made a little test whish almost gave me an heart attack! l_time doesn’t return 0 but ~2 sec… whish doesn’t make any sense.

2 seconds? Really? Can I see your complete code, and how you display the result?

[golgoth]

You know when you send a thread to sleep, but you don't know exactly when the OS will make it wake up. Once the OS switches to another thread, it may be busy longer than the amount of ms that you passed to sf::Sleep, this value is only a hint.

Seriously? I should know because I send the exact time via Sleep… why would another thread have an effect of this?

In my opinion this is a very specific topic, and it may require more complex things than Sleep().

Accuracy shouldn’t be a specific topic though, video playback is fairly simple, what makes it mind boggling is not knowing there is randomness in the timing functions and especially pipe locks within SwapBuffers.

Code: [Select]


Int main(Int in_argc, Char **in_argv)
{
sf::Clock l_clock;
l_clock.Reset();
Float l_time = l_clock.GetElapsedTime();
return 0; /// <- break here!
}
I took for granted timing related functions were rock solid. (A special note is needed in the documentation) I’m just going to build my own timing functions but, why not implement the Ogre technique within SFML to fix the bug?

Let me know if you have any development on this.

[Laurent]

Seriously? I should know because I send the exact time via Sleep… why would another thread have an effect of this?

Because there's only one OS, a few CPU cores, and hundreds of threads to run. Once your thread sleeps, there are a lot of things to do for the CPU, the OS scheduler can't guarantee your thread to come back to top priority as soon as you want.

why not implement the Ogre technique within SFML to fix the bug?

It's not straight-forward.
But guess what? It's in the task tracker so it means that it's going to be implemented

I don't know how to help you more, but I really think that other video players (source codes, blogs, tutorials, ...) can help you better.

[golgoth]

But guess what? It's in the task tracker so it means that it's going to be implemented

Well I hope it is a top priority.

Actually you help me a lot, so now I have a good understanding of what is going on! thx again for your help!

[golgoth]

This seems to work very well:

Code: [Select]

#include <time.h>

Double System::GetSeconds()
{
return (Double) clock() / CLOCKS_PER_SEC;
}

Int64 System::GetMicroseconds()
{
return (Int64) clock() * CLOCKS_PER_SEC;
}

Int64 System::GetMilliseconds()
{
return (Int64) clock();
}

// Pauses for a specified number of milliseconds.
void System::Sleep(Int64 in_milliseconds)
{
Int64 l_goal;
l_goal = in_milliseconds + clock();
while (l_goal > clock());
}

Am I missing anything?

EDIT: time.h is ansi so it should be cross platform.

[Nexus]

Am I missing anything?

Yes, you implemented busy-wait, not sleep. In contrast to sf::Sleep(), the CPU core is running at 100% until the time is over.

Apart from that, the standard clock may not have a high enough resolution.

[Silvah]

Apart from what Nexus said,

This seems to work very well

It doesn't. clock() doesn't necessarily return milliseconds (for example, on POSIX-compatible platforms it has to return microseconds).

[golgoth]

Yes, you implemented busy-wait, not sleep. In contrast to sf::Sleep(), the CPU core is running at 100% until the time is over.

Oups, you are so right, I guess I have no choice to use sf::Sleep, or do I?

Apart from that, the standard clock may not have a high enough resolution.

Ok now I’m getting cranky… what is wrong with the resolution?

It doesn't. clock() doesn't necessarily return milliseconds (for example, on POSIX-compatible platforms it has to return microseconds).

Ok, that’s an easy fix though, but I’m telling you guys, more  I’m digging into programming, more I’m disappointed to see how people agree to make standards by making more of them.

Wasting time makes me nervous so I need a clock with ”with enough resolution”. Anyone aware of another cross-platform solution that does the job right?

[golgoth]

I should add that regardless of Sleep(), the functions using clock() I’ve posted earlier did solve my timing issues when playing video.

However, when I turn the audio on, I’m getting latency and I was wondering if sf::SoundStream has any timing issue I should be aware of? Is it using ::Clock ::Sleep or any other timing methods?

[l0calh05t]

I should add that regardless of Sleep(), the functions using clock() I’ve posted earlier did solve my timing issues when playing video.

However, when I turn the audio on, I’m getting latency and I was wondering if sf::SoundStream has any timing issue I should be aware of? Is it using ::Clock ::Sleep or any other timing methods?

Audio latency depends on the buffer size used. But you cannot reduce the buffer size arbitrarily, as a smaller buffer costs more performance (and increases the risk of dropouts). If your audio is lagging behind video, you could get back in sync by delaying video (or vice versa if video is lagging)

[Ceylo]

Wasting time makes me nervous so I need a clock with ”with enough resolution”. Anyone aware of another cross-platform solution that does the job right?

You'll find no way on the main user operating systems, because of the way multi task OS work.

Since the OS is supposed to let several programs (and threads) work on the same core, it has to give a little amount of time for each of the threads that need CPU time. And when this amount is elapsed, it switches to the next thread (basically). Thus if other threads need CPU time, you can't know when YOUR thread will get the CPU ressources back.