Clock and openGL

[HylianEvil]

Hello, I'm pretty new here and new to game programming in general.
What I'm trying to do is make a game in openGL/SFML 1.6 and I realized that I need
a clock to have the same experience independent of how fast someone's computer is.

What I'm doing is something like this

void Sprite::updateX(float tempX)
{
   x += tempX*Clock->GetElapsedTime();
}

I've noticed there's a stutter in my animations that happens predictably with time.

Does anyone know a good tutorial on setting up a clock for use in a game or does anyone know how to properly use the clock feature to get rid of this stutter?

[MorleyDev]

With your code, x will increase exponentially and your animation will be jumping ahead by multiple frames every update. GetElapsedTime gets the time since the program started, which is constantly increasing. You want the change in time between the last call and this one.

[HylianEvil]

Oops, sorry for being vague. I actually call Clock->Reset(); at the end of my game loop.

[Cornstalks]

You should probably use one timestamp for the entire update cycle. That is, think of it this way: You begin updating your sprites at time t = 0. You call update on the first sprite, and Clock->GetElapsedTime(); returns 0.0001 for that sprite. You call update on the second sprite, and Clock->GetElapsedTime(); returns 0.0002 for that sprite, and so on. In other words, each sprite is using a different update time, even though it's all part of the same update cycle!

This may or may not be causing your problem, but it's probably not helping, at least. What you can do that would help is pass in the current update time so that all sprites use the same update time. That is, in your main loop, you call Clock->GetElapsedTime(); and you store the returned time in a variable, and then you pass that variable to each sprite as the current time stamp. That way, each sprite uses the same update time, and they stay in sync better.

[HylianEvil]

Ah. that's a very good point. I've implemented your suggestion but I am still experiencing the choppiness.

[HylianEvil]

So, instead of using

   "App->SetFramerateLimit(60);"

I've just put 

   while (Clock->GetElapsedTime() < 1.0/60.0);
   Clock->Reset();

at the end of my game loop. This seems to give a stable frame rate but it's only a temporary solution.
Here's some of my code.

https://gist.github.com/2505308

[eXpl0it3r]

I've just put 

   while (Clock->GetElapsedTime() < 1.0/60.0);
   Clock->Reset();

at the end of my game loop. This seems to give a stable frame rate but it's only a temporary solution.
Here's some of my code.

It only gives you a stable framerate as long as the update & draw scetions take only a very small timespan. Because what the code does now is, it waits/loops for 1/60s every frame. So the actually time consumed per frame is update+draw+1/60s which isn't equal to 1/60s.
In addition to that you've created a busy-waiting construct, which means it will use the complete CPU instead of just idle for 1/60s. If you just want to let the thread pause then use sf::Sleep.

SetFramerateLimit does not guarantee a stable framerate if you want one and 60fps are enough then just use vsync.

[HylianEvil]

I do have "App->UseVerticalSync(true);"
declared in in my code but my frame rate seems to go way higher than 60fps.
I have no idea why it would do that :/ because my monitor is set to a refresh rate of 60hertz.

[eXpl0it3r]

If you search a bit in the forum you'll find various threads about SFML 1.6 and its bad handling of vsync and framerate limit, that's another reason why SFML 1.6 should be deapreciated...
Just switch to SFML 2. It's not that much of work (i.e. the time you've spend on figuring stuff out why you get such a high framerate is already bigger than the time it would take to convert your code)

[Plaid Phantom]

Building on what Cornstalks recommended, are you still resetting the Clock at the end of the game loop?  If so, then your elapsed time will not include the time it took to update all of your sprites (and possibly the draw time, depending on your exact code).  You might make sure that you reset the clock the next instruction after the call to GetElapsedTime.  If you don't do that, then your sprites will move more slowly than they need to, and it will only get worse as you add more sprites.

[HylianEvil]

Ah, thanks for the replies.
I think I will switch to 2.0. I've been reading up on various methods for handling time and I believe a bit of the problem I am having is a lack of an understanding of how to actually use time with my animations. (This is my first time having to use time in a program lol).

Anyways... I'm going to read up on time management a bit more and then try to switch my program over to 2.0.

Thanks for your patients guys . I feel I have handled the description of my problem poorly lol. And I appreciate the replies. Stick with me I'll get better at the whole forum thing!

[MorleyDev]

Also to pop my head back in: http://gafferongames.com/game-physics/fix-your-timestep/
I need to bookmark that page I pass it around so often.

[eXpl0it3r]

Also to pop my head back in: http://gafferongames.com/game-physics/fix-your-timestep/
I need to bookmark that page I pass it around so often.

I have it bookmarked, after the last time you've posted it somewhere.