Problem with fixed time step

[Kyoya]

I have a short question. I am learning SFML and I made few apps by using it. Someday I learned about using fixed time step while coding games and it would be great if it worked. BUT. Even though I am making simple project like square moving from left to right side of the window - it is lagging! What could be a cause of this problem? This is some simple code, which contains this problem:

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Window");
    sf::Event event;
    sf::Clock clock;
    sf::Time accumulator = sf::Time::Zero;
    const sf::Time timePerFrame = sf::seconds(1.f / 60.f);
    sf::RectangleShape square;
    square.setSize(sf::Vector2f(32, 32));
    square.setOrigin(16, 16);
    square.setPosition(400, 300);
    square.setFillColor(sf::Color::Red);
    int direction = 1;
    int speed = 300;
    while(window.isOpen())
    {
        while(window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
            {
                window.close();
            }
        }
        while(accumulator >= timePerFrame)
        {
            if(square.getPosition().x <= 16 || square.getPosition().x >= 784) direction *= (-1);
            square.move(sf::Vector2f(speed * direction * timePerFrame.asSeconds(), 0));
            accumulator -= timePerFrame;
        }
        accumulator += clock.restart();
        window.clear(sf::Color::Black);
        window.draw(square);
        window.display();
    }
    return 0;
}
 

I don't want to use vertical synchronization, because I read that it shouldn't be used with fixed time step. Any help is appreciated!

@Edit: My problem looks similar to this:

[eXpl0it3r]

Your implementation skipped over the final part of this article: http://gafferongames.com/game-physics/fix-your-timestep/

What you see in the linked video is the key repeat kicking in, so not lagging. Is that what you're really seeing?

If you use an Nvidia GPU try disabling the Multi-Threaded option in the Nvidia settings.

[Kyoya]

What exactly is wrong with my game loop? Problem which I described takes place on every PC where I tried to use my program. So, I think it's not related with GPU. This code is quite simple, so I have no idea what's wrong.

[Hapax]

If it is the tearing and not the lagging that is the problem, the only solution is vertical synchronisation.

I don't want to use vertical synchronization, because I read that it shouldn't be used with fixed time step.

I'm not sure where you read this but there should not be anything wrong with using vertical synchronisation with fixed timestep as long as that timestep is looped until the frame's time has passed. It seems you are performing this part in your code so I would not expect vertical synchronisation to cause you any problems.

It's possible that a fixed timestep that only processes a certain timestep once per frame could be problematic since that timestep and the frame length may differ. Although, if you use v-sync, that frame is likely to be fixed most of the time anyway.

The author of the "Fix Your Timestep" article - linked above by eXpl0it3r - has insisted that every game should be vertically synchronised by default and only disabled if there is a very good reason. Although you may consider this extreme or just simply disagree with it, it does show that v-sync and fixed timestep (with the "physics freed") can work well together.

[Kyoya]

In my case, if I'm trying to use both at the same time - application is lagging. Anyway, this is a quote from sfml tutorial page:

Never use both setVerticalSyncEnabled and setFramerateLimit at the same time! They would badly mix and make things worse.

And this is a code of setFrameLimit function:

void Window::setFramerateLimit(unsigned int limit)
{
    if (limit > 0)
        m_frameTimeLimit = seconds(1.f / limit);
    else
        m_frameTimeLimit = Time::Zero;
}

This is display function:

void Window::display()
{
    // Display the backbuffer on screen
    if (setActive())
        m_context->display();

    // Limit the framerate if needed
    if (m_frameTimeLimit != Time::Zero)
    {
        sleep(m_frameTimeLimit - m_clock.getElapsedTime());
        m_clock.restart();
    }
}

I think that my "fixed time step" loop looks almost the same. So I assume that I shouldn't use them at the same time. Even though it's not true, my program is lagging when I use both. What causes it? This is so simple piece of code, I'm feeling bad having problems with it. 

@Edit: This is video showing what is going on when I'm trying to use both of them: http://sendvid.com/6vr22pn2

[Hapax]

It is true that you should not use vertical synchronisation at the same time as limiting the framerate. The answer, then, to using v-sync is to not use a framerate limit.

Your code in your original post is not the same as limiting the framerate. Your code allows any framerate it can muster but only processes it in little "chunks" of fixed timesteps whereas limiting the framerate is done by sleeping the thread; your code doesn't sleep, which is the thing that causes problems with synchronisation - v-sync effectively pauses at the "window.display();" line until the display is ready to receive the image and then draws it at the correct time, thus limiting the framerate to - at most - the display's refresh rate.
Basically, since v-sync is waiting for certain times, adding extra pauses/sleeps may not match and can push that synchronisation to the following refresh, causing stutters or much slower refreshes.

[Kyoya]

Thank you for the explanation.  I added link to video in my previous post. Check it out, because it shows what is my problem while using v-sync. FPS is set 60 and no, my computer is not that slow. 

[Hapax]

The problem in the video that I see is the "tearing". The solution to that is using v-sync.

If you use v-sync, you should not also use a framerate limit. It's already limited to the nearest display refresh by the v-sync. Try it without the limit.

Note that v-sync is a graphics card implementation. Enabling v-sync using SFML is effectively sending a request to the graphics driver asking it to be enabled. The driver, however, may have reason not to fulfil such a request, such as not having v-sync ability (unlikely) or the driver's user settings having switch off v-sync globally or for specific applications (common). In graphics settings, the common basic three settings for v-sync are: always on, always off, and application-controlled. If always off, any requests by applications to enable v-sync will be ignored. Also, many graphics settings also allow this setting to be customised per application.