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

Author Topic: Clock and openGL  (Read 4754 times)

0 Members and 1 Guest are viewing this topic.

HylianEvil

  • Newbie
  • *
  • Posts: 6
    • View Profile
Clock and openGL
« on: April 25, 2012, 11:42:08 pm »
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

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: Clock and openGL
« Reply #1 on: April 26, 2012, 12:03:06 am »
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.
« Last Edit: April 26, 2012, 12:10:35 am by MorleyDev »
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

HylianEvil

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Clock and openGL
« Reply #2 on: April 26, 2012, 12:17:17 am »
Oops, sorry for being vague. I actually call Clock->Reset(); at the end of my game loop.

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
Re: Clock and openGL
« Reply #3 on: April 26, 2012, 05:35:26 am »
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

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Clock and openGL
« Reply #4 on: April 26, 2012, 08:34:34 am »
Ah. that's a very good point. I've implemented your suggestion but I am still experiencing the choppiness.

HylianEvil

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Clock and openGL
« Reply #5 on: April 27, 2012, 04:59:09 am »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Clock and openGL
« Reply #6 on: April 27, 2012, 01:00:43 pm »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

HylianEvil

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Clock and openGL
« Reply #7 on: April 27, 2012, 09:07:54 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Clock and openGL
« Reply #8 on: April 27, 2012, 11:42:02 pm »
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) ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Plaid Phantom

  • Newbie
  • *
  • Posts: 10
    • View Profile
Re: Clock and openGL
« Reply #9 on: April 28, 2012, 02:27:35 am »
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

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Clock and openGL
« Reply #10 on: April 28, 2012, 06:40:12 am »
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

  • Full Member
  • ***
  • Posts: 219
  • "It is not enough for code to work."
    • View Profile
    • http://www.morleydev.co.uk/
Re: Clock and openGL
« Reply #11 on: April 29, 2012, 02:57:15 am »
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.
UnitTest11 - A unit testing library in C++ written to take advantage of C++11.

All code is guilty until proven innocent, unworthy until tested, and pointless without singular and well-defined purpose.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Clock and openGL
« Reply #12 on: April 29, 2012, 10:46:36 pm »
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.  ;D
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

 

anything