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

Author Topic: Double Precision  (Read 8976 times)

0 Members and 2 Guests are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Double Precision
« Reply #15 on: February 05, 2011, 09:31:46 am »
Please use the "quote" tag, it makes your posts clearer when you quote other people ;)

Quote
Sorry what bug?

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

Quote
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.

Quote
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().

Quote
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?
Laurent Gomila - SFML developer

golgoth

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Double Precision
« Reply #16 on: February 05, 2011, 06:15:54 pm »
Quote
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?

Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Double Precision
« Reply #17 on: February 05, 2011, 06:42:47 pm »
Quote
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.

Quote
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.
Laurent Gomila - SFML developer

golgoth

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Double Precision
« Reply #18 on: February 05, 2011, 07:36:01 pm »
Quote
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

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Double Precision
« Reply #19 on: February 05, 2011, 09:40:17 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Double Precision
« Reply #20 on: February 05, 2011, 11:58:36 pm »
Quote from: "golgoth"
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Silvah

  • Guest
Double Precision
« Reply #21 on: February 06, 2011, 11:10:25 am »
Apart from what Nexus said,
Quote from: "golgoth"
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

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Double Precision
« Reply #22 on: February 06, 2011, 05:10:37 pm »
Quote
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?

Quote
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?

Quote
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

  • Jr. Member
  • **
  • Posts: 99
    • View Profile
Double Precision
« Reply #23 on: February 06, 2011, 05:27:53 pm »
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

  • Full Member
  • ***
  • Posts: 200
    • View Profile
Double Precision
« Reply #24 on: February 06, 2011, 06:04:53 pm »
Quote from: "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?


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

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
Double Precision
« Reply #25 on: February 06, 2011, 08:24:58 pm »
Quote from: "golgoth"
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.
Want to play movies in your SFML application? Check out sfeMovie!