Strange Movement with Fixed Timestep

[Hapax]

Try timing the frames and outputting that information to see if there any unusual spikes.

Like with my application commenting out this code in your example makes the issue go away:

sf::Event event;
while(window.pollEvent(event))
{
        // ...
}

You shouldn't remove this. It's very important that a window deals with its events. Every application must do this; if it doesn't, the operating system is likely to consider the application as unresponsive/crashed and may close it.
Plus, how else would you close the window?

[Mr_Blame]

This may be std::queue allocation issue(SFML uses std::queue for event handling)

[Carlitox]

I'm having the same problem but only in the window mode and no so often, it's a stuttering that happens suddendly each 2 seconds when moving the map at high velocity.

I'm using kairos and doing interpolation at 60 fps. What i look strange is that fps is 59.5 and not 60 in the computer that causes the problem.

PD: It seems a problem of cpu or memory usage because if i restart laptop and pc it doesn't happen the stuttering. It comes with time.

[CasualKyle]

Try timing the frames and outputting that information to see if there any unusual spikes.

I'm restarting an sf::Clock just before the window is rendered. Then I'm subtracting away the previous frame time from that time and printing out "--- stutter ---" if the difference is > 0.05. Okay so during the simulation I noticed it stuttered about 5 or 6 times (I didn't run the application for very long) and this is the output which you can see 6 times "--- stutter ---" was printed. So yeah it looks like the window isn't getting rendered consistently.

I'm holding down the right arrow key so as soon as the application starts the circle moves to the right and when it get's to the end I close it down so the application isn't running for very long. Then I'm printing out the x position of the circle and if the current position - previous position > 5 I'm printing out "--- stutter ---". Here's the output for the x position of the circle. If you put the two outputs side by side the stutter output line's line up. (Also the position of the circle is being rounded which is why they're whole numbers)

PD: It seems a problem of cpu or memory usage because if i restart laptop and pc it doesn't happen the stuttering. It comes with time.

Same with me when I restart my  computer it goes away just to come back later in the day.

[Hapax]

"- stutter -"
Yes, it looks like your frame is being delayed quite unusually. Try closing other things you have running to see if it's being affected by those. Also, try running the built release executable directly.

If those still cause the delayed frames, try increasing their priority to see if that changes anything; it could be an indication that something is hogging the CPU when it wants to use it.

Make sure your graphics card drivers are up-to-date.

Note: rounding positions helps with displaying pixel accuracy but can also create its own stuttering affect as whole number aren't the exact position that it should be. You could try without rounding to see if it helps with motion.

[Carlitox]

If the positions are interpolated to make smooth movements that means that i must use non integer values for moving views. ¿That will cause problems? ¿What i should do?

I was using this function to store the decimals and only setting positions with integer values.

void Movement::moveNowInteger(sf::Vector2f n)
{
        if(n.x > 0.f) process_move_right += n.x;
        if (n.x < 0.f) process_move_left += (-n.x);
        if (n.y > 0.f) process_move_down += n.y;
        if (n.y < 0.f) process_move_up += (-n.y);
       
        if (process_move_right > 1.f)
        {
                moveNow(sf::Vector2f(std::floor(process_move_right), 0.f));
                process_move_right -= std::floor(process_move_right);
        }
        else if (process_move_left > 1.f)
        {
                moveNow(sf::Vector2f(-std::floor(process_move_left), 0.f));
                process_move_left -= std::floor(process_move_left);
        }

        if (process_move_down > 1.f)
        {
                moveNow(sf::Vector2f(0.f, std::floor(process_move_down)));
                process_move_down -= std::floor(process_move_down) ;

        }
        if (process_move_up > 1.f)
        {
                moveNow(sf::Vector2f(0.f, -std::floor(process_move_up)));
                process_move_up -= std::floor(process_move_up);
        }
}

Currently i'm integrating your kairos library to my game and i can move the view with a smooth movement and without flickering. The problem comes when i keep the program 1 minute or more moving the camera, it begins stuttering exaggeratedly.

[Hapax]

If it stuttering when moving the view (your camera is a view?), it could be the way you update based on the current view that is slowing things down. Are you drawing everything offscreen at all times as well, or are you only drawing things that are visible by testing to see if they're in the view?

Non-integer values can be fine. They can cause troubles with some rasterisation - with textures in particular. You can use integer values to help avoid these troubles, which include gaps in tilemaps. However, using integer values for positions when in motion mean that the values aren't exactly correct and therefore can cause a slight stuttering effect. In this case, it's a tradeoff: smooth motion or perfect rasterisation. There are, of course, other ways to avoid rasterisation troubles. They depend on the troubles you are facing.

Is this a tile map over which you are moving the camera?

[Carlitox]

If it stuttering when moving the view (your camera is a view?), it could be the way you update based on the current view that is slowing things down. Are you drawing everything offscreen at all times as well, or are you only drawing things that are visible by testing to see if they're in the view?

Non-integer values can be fine. They can cause troubles with some rasterisation - with textures in particular. You can use integer values to help avoid these troubles, which include gaps in tilemaps. However, using integer values for positions when in motion mean that the values aren't exactly correct and therefore can cause a slight stuttering effect. In this case, it's a tradeoff: smooth motion or perfect rasterisation. There are, of course, other ways to avoid rasterisation troubles. They depend on the troubles you are facing.

Is this a tile map over which you are moving the camera?

The vertex array was 100x100 tiles with 4 layers 

I made it 40x10 and had the same issue but with lower cpu.

The problem was in the transitions between scenerios, i move the camera like in megaman and then run a lua script to load enemies that causes  fps go from 60 to 55 generating the graphics corruption with the time. Having mozilla opened causes a little stuttering every minute but not causes the massive corruption of graphics like the script.

Tomorrow i will play more time and see if the problem is reproduced or not. I have to work in an algorithm to resize the vertex array every second to allow big levels at low cpu and less memory usage.

[Hapax]

The problem was in the transitions between scenerios, i move the camera like in megaman and then run a lua script to load enemies that causes  fps go from 60 to 55 generating the graphics corruption with the time.

Is this file access?
Does this camera move still stutter without this loading?

[Carlitox]

The problem was in the transitions between scenerios, i move the camera like in megaman and then run a lua script to load enemies that causes  fps go from 60 to 55 generating the graphics corruption with the time.

Is this file access?
Does this camera move still stutter without this loading?

The problem has been solved and has nothing to do with scripts, just was a collateral effect. The problem was that i was updating everything in this loop

while (timestep.isTimeToIntegrate())
{

..
update(dt);
 ..

}

Now i'm updating with your library in my MovementComponent class and in the Camera class and i quit this checking in the gameloop. I need to read more about time controlling and understand better your library.

[Hapax]

I'd highly recommend using Timestep instead of TimestepLite; it does more of the work for you.

If you have any questions about Kairos (or any of my libraries/projects), feel free to ask; I'll help the best I can.

[CasualKyle]

So I updated my graphics drivers which was actually one of the first things I thought to do upon encountering this issue. The problem was that I was using the Intel Driver Update Utility tool which told me that my graphics drivers did not need to be updated. It turns out they were not up to date. It's been over two days now and I have not experienced the issue since manually updating the drivers. I'll report back if I experience it again but for now if anyone has the same problem with their application go to the manufacture's website and download and install the graphics drivers manually. If you have integrated graphics on an Intel CPU do not trust the Intel Driver Update Utility tool it did not show that my graphics drivers were not up to date so it might do the same to you.

[CasualKyle]

Never mind the issue is back, updating the graphics drivers did not work.

Yes, it looks like your frame is being delayed quite unusually. Try closing other things you have running to see if it's being affected by those. Also, try running the built release executable directly.

No change.

If those still cause the delayed frames, try increasing their priority to see if that changes anything; it could be an indication that something is hogging the CPU when it wants to use it.

Also no change.

Make sure your graphics card drivers are up-to-date.

I've done so, no change.

[Carlitox]

Put updateStates(dt) after the while loop not in it and before the rendering and activate vsync and look what happens.

[Hapax]

Put updateStates(dt) after the while loop not in it and before the rendering and activate vsync and look what happens.

That would defeat the object of fixed timestep and each update would happen once per frame regardless of how long that frame took.