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

Author Topic: Handling sf::Clock inconsistent times  (Read 3569 times)

0 Members and 1 Guest are viewing this topic.

JesseGuarascia

  • Newbie
  • *
  • Posts: 2
    • View Profile
    • Email
Handling sf::Clock inconsistent times
« on: April 30, 2014, 10:47:08 pm »
So I've been working with SFML for a little while now and wanted to try using delta time to move an object in game. Here's my code:

        AssetManager::LoadTexture("player");
        VideoManager vm;
        Paddle paddle;

        sf::Clock clock;
        sf::Time time = sf::milliseconds(0);
        float lastDelta = 0;

        while (vm.isWindowOpen())
    {
                vm.Update();

                sf::Time curTime = clock.getElapsedTime();
                sf::Time frameDelta = curTime - time;
               
                std::cout << frameDelta.asMilliseconds() << std::endl;

                paddle.Update(frameDelta.asMilliseconds());

                time = curTime;

                vm.Clear();
                paddle.Render(&vm);
                vm.Display();
    }

        AssetManager::UnloadAssets();

    return 0;

The problem is though that I get some strange timings in the system that seems to be messing with the movement of the object and resulting in it sort of skipping ahead a little bit sometimes. I'm getting a pretty constant 16 milliseconds per update with vsync on, but sometimes it becomes 17 (rounding, makes sense I suppose) or in some sort of common instances, it becomes 33 or 1 or 0 and I would be okay with this if it wasn't for the fact that the skipping around of the object is somewhat noticeable. Is there any way to deal with this big time jump? The 33 milliseconds literally skips the object ahead, it's really annoying for me.

Not sure if the object movement code is relevant but here it is:
        sf::Vector2f vel;

        // Use user input to determine direction of paddle
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::D)){
                vel.x = PADDLE_SPEED;
        } else if (sf::Keyboard::isKeyPressed(sf::Keyboard::A)){
                vel.x = -PADDLE_SPEED;
        }

        pos.x += vel.x * (delta / 1000.f);
        pos.y += vel.y * (delta / 1000.f);
 

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Handling sf::Clock inconsistent times
« Reply #1 on: May 01, 2014, 01:40:21 am »
You could always try to use asMicroseconds() to eliminate the 0 time case where time gets lost due to insufficient precision. For the opposite case where there are occasionally frames that take double as long, this is due to the way the operating system schedules tasks. There is nothing you can really do about it. All real-time applications that don't run on dedicated hardware have to tolerate with this fact. I am still surprised that an extra 16ms results in such a noticeable effect in your game. I assume your PADDLE_SPEED is in pixels/second so whether that second comprises of many 16ms frames without 33ms frames or many 16ms frames with a few 33ms frames, it really shouldn't have a noticeable impact on the average velocity of the paddle. Did you rule out anything else that might be causing this?
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

JesseGuarascia

  • Newbie
  • *
  • Posts: 2
    • View Profile
    • Email
Re: Handling sf::Clock inconsistent times
« Reply #2 on: May 01, 2014, 01:59:58 am »
It's not a HUGE jump ahead, but I'm extremely picky and sometimes can notice stuff like that. Just bugs me seeing that little jump even though you're definitely not paying attention to that stuff when playing the game. Thanks for clearing up why the timing might happen like that. Much appreciated

 

anything