My timestep code isn't working, completely baffled

[Insentience]

#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>
#include <iostream>

static const int FRAME_LIMIT = 120;

bool WINDOW_FOCUS = true;

const sf::Time TICK_INTERVAL = sf::seconds(1.0f / FRAME_LIMIT);

int main()
{
    // Create the main rendering window
    sf::RenderWindow window(sf::VideoMode(768, 768), "SFML works!");
    sf::RectangleShape Rectangle;

    Rectangle.setSize(sf::Vector2f(300, 300));
    Rectangle.setPosition(150, 150);
    Rectangle.setFillColor(sf::Color::Blue);
    Rectangle.setOutlineThickness(1.0f);
    Rectangle.setOutlineColor(sf::Color::White);

    sf::Clock clock;
    sf::Time accumulatedTime;

    clock.restart();

    //Yes, I've tried commenting out the following line. Nothing changed
    window.setFramerateLimit(FRAME_LIMIT);
   
    //LOOP UNTIL YOU DONT WANT IT TO
    while (window.isOpen())
    {
       
      //WINDOW EVENTS (ignore this)
      sf::Event event;
      while (window.pollEvent(event))
      {
        if (event.type == sf::Event::Closed)
          window.close();
      }
     
      //TIME CALCULATIONS
      accumulatedTime += clock.restart();//.asMilliseconds();
     
      //PHYSICS CODE
      while(accumulatedTime >= TICK_INTERVAL)
      {
        accumulatedTime -= TICK_INTERVAL;
        if (sf::Keyboard::isKeyPressed(sf::Keyboard::A))
        {
          // left key is pressed: move our character
          Rectangle.move(-0.1f, 0);
        }
        else if (sf::Keyboard::isKeyPressed(sf::Keyboard::D))
        {
          Rectangle.move(0.1f, 0);
        }

        if (sf::Keyboard::isKeyPressed(sf::Keyboard::W))
        {
          // left key is pressed: move our character
          Rectangle.move(0, -0.1f);
        }
        else if (sf::Keyboard::isKeyPressed(sf::Keyboard::S))
        {
          Rectangle.move(0, 0.1f);
        }
      }
     
      //DRAWING
      window.clear();
      window.draw(Rectangle);
      window.display();
    }

    return EXIT_SUCCESS;
}
 

With this code, the rectangle's movements are very choppy. I really don't know what I'm doing wrong. I tried the other way (multiplying rectangle move value by deltaTime) and the movement was awesome! Smooth! Pleasant to look at! However, multiplying by deltaTime all the time is tedious and annoying.

I would love some help.

[4B]

Can someone or you explain, why you need this?
With a fps-limit of 60 it's moving smoothly, too.

And you should put the if-statements for the keys into the window.pollEvent()-loop.

Style:
Why you need to define the variables global?
Why you got a capital letter for rectangle?
Why you dont set the framerate limit directly after the initialization of your window?

[G.]

And you should put the if-statements for the keys into the window.pollEvent()-loop.

Absolutely not...

[4B]

Absolutely not...

Tell me why.

[Insentience]

Can someone or you explain, why you need this?
With a fps-limit of 60 it's moving smoothly, too.

You can't assume that your game will run at that consistent framerate on every computer. It's a rookie mistake.

Also, I didn't create this thread to learn about proper programming practice. This is a simple example I whipped up that uses similar timestep code found in my project. Don't derail the topic, please.

[4B]

If it's running on a lower fps than 60 you've done something wrong in resource-handling.

Anyway.. You can still make your life easier. Just store a clock.restart() to passedTime each frame and multiply your 1.0f * passedTime .
If I still didn't unterstood what you want to know, I'm done.

[zsbzsb]

Tell me why.

For crying out loud, can you not search? Because those ifs have absolutely nothing to do with the event loop. 

If it's running on a lower fps than 60 you've done something wrong in resource-handling.

Not true at all..... please learn about something before talking like you know it. 

[Insentience]

If it's running on a lower fps than 60 you've done something wrong in resource-handling.

Ok I think you need to relax

This is a simple example. Simple. I wrote this example and made sure to use the same timestep code that was in my project. Why? Because I wanted to ask people on this forum why my timestep code isn't working properly, and I didn't want to boggle them down with about 14,000 lines of source code. If you want 14,000 lines of source code to look at be my guest.

Because this example is simple, it will always run at a high framerate. However, my project is a lot more sophisticated, and I cannot guarantee that lower end machines will be able to run it at a constant 60 frames per second.

Do you understand? Now please cut the snarky attitude, it's embarrassing.

Anyway.. You can still make your life easier. Just store a clock.restart() to passedTime each frame and multiply your 1.0f * passedTime .
If I still didn't unterstood what you want to know, I'm done.

I know, and I explained in the opening post that I wanted to avoid multiplying a lot of my physics by deltaTime. It results in cluttering.

Of course, since this is a simple example, multiplying the move values by deltaTime is no big deal. However, as I've mentioned, my project is a lot more sophisticated than this.

[4B]

For crying out loud, can you not search? Because those ifs have absolutely nothing to do with the event loop. 

Not true at all..... please learn about something before talking like you know it. 

You guys are toxic as hell.

I told him how to improve his style/code. There's a reason why i splitted it from the other points, because the three others are definitly bad style. It's looking way better if keys&events are seperated from other calculations(my opinion). You can't and shouldn't flame me for what I prefer. If you don't like it, you can give your opinion and stay calm.

PLEASE read my signature.

@Insentience I'm relaxing, but you've got some serious problems and I just wanted to help.

@moderator sorry for off-topic, but his behaviour is bad.

[Insentience]

You guys are toxic as hell.

I told him how to improve his style/code. There's a reason why i splitted it from the other points, because the three others are definitly bad style. It's looking way better if keys&events are seperated from other calculations(my opinion). You can't and shouldn't flame me for what I prefer. If you don't like it, you can give your opinion and stay calm.

You went off on an unrelated tangent.

If someone asked for advice on how to study for an exam, do you tell him to buy a new pair of shoes?

You came off as very condescending, which I did not appreciate.

Now can everyone relax and just help me out? If I wanted a flamewar I'd have gone onto some chan website.

[Ixrec]

Ignoring all of the previous replies...

With this code, the rectangle's movements are very choppy. I really don't know what I'm doing wrong. I tried the other way (multiplying rectangle move value by deltaTime) and the movement was awesome! Smooth! Pleasant to look at! However, multiplying by deltaTime all the time is tedious and annoying.

I would love some help.

I think the long and short answer to your question is that multiplying by delta time is the simplest and most effective way to get framerate-independent movement in most cases*.

One of many little points to think about: with deltaTime the rectangle is guaranteed to move exactly once every frame at least a little bit, but with accumulatedTime there will probably be some frames where it doesn't move at all, and other frames where it moves several times before getting drawn.

You can probably tweak the accumulatedTime implementation to minimize certain things like this, but in general the fact that deltaTime "just works" better than other methods is, afaik, inescapable.  Also, if you design your drawable/movable classes well (feel free to ask for help with this) you shouldn't have to explicitly multiply by deltaTime very much outside of main(), so it's not that annoying in the long run.  To be honest I find it much more irritating to maintain a counter and do an arbitrary number of loops over the movement logic each frame.


*By "most cases", I'm excluding things like multiplayer strategy games with replay functionality, where desync can only be prevented by enforcing a fixed timestep.  Most programs do not need to go this far.

[Grimshaw]

4B, please don't pollute the thread anymore. The OP asked a valid question, you then proceed to claim you are helping him improve when you don't seem to know what you're talking about both by inexperience and lack of reading the documentation, then you claim we are the toxic ones..

I don't want to be rude, but please stop that