Weird behaviour when moving window

[smguyk]

I am working on a platformer with a tile map and collision and stuff. Today I moved the window to see the console output (because the console window was hidden behind my game's window) and to my surprise my character fell through solid tiles and even out of the map's boundaries.

So I did a little testing and it turns out this only happens when I drag the window around. Why is this happening? This could also be potentially disastrous for my game (it crashes for collision testing outside a certain area) but that's not the point. Is there a way to circumvent this? Like either this not happening at all or simply stop updating the game whilst the window is being dragged?

I could make the game full screen but I also want to support windowed mode...

Thanks

[Laurent]

This is because the execution is blocked while you move the window. So when you release the mouse button, it suddenly resumes with a huge delta time and makes all your calculations go crazy.

Simple and ugly solution: skip the current frame when delta time is greater than ~1 second.
Robust solution: use a fixed timestep algorithm.
Other robust solution: handle events in a separate thread so that the logic and drawing are not blocked while you move the window

[binary1248]

Simple and ugly solution: skip the current frame when delta time is greater than ~1 second.
Robust solution: use a fixed timestep algorithm.
Other robust solution: handle events in a separate thread so that the logic and drawing are not blocked while you move the window

The truly robust solution: fix the physics engine . This can be blamed on having a large delta, however, robust physics engines already reckoned with this case and have counter-measures for it or were designed in a way that is not susceptible to the problem from the start. Even with a fixed timestep, if the objects are really really small, then they can still ghost through in certain situations. Threading doesn't help you here either.

I just did a quick Google search and one possible solution is described here:
http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/

[smguyk]

Thanks guys.

I really like the multi-thread idea but I've never worked with threads so that kind of scares me off a bit.

Anyway, I "fixed" it by limiting the passed delta to 1/15 of a second if it exceeds that.

It's not really ideal but I think it's fine, right? Or do you see any problems with that?

[Jesper Juhl]

What I personally do in my own projects to avoid this, and other, issue(s) is to use a fixed time step to update my game state. Essentially this in my game loop (pseudo code):

step = 16ms
for each frame:
  while (elapsed_time >= step) {
    do_update(step)
    elapsed_time -= step
  }
  draw_frame()

All my update functions then take the passed step into account when determining how much to update/move/whatever so I can easily change the step value and stuff just do the right thing and I also know that I can count on the time passed during each update to be a sane value (and the same for each step), so stuff like collision detection and whatnot won't do crazy things.

This is basically the technique described in http://gafferongames.com/game-physics/fix-your-timestep/ - I suggest reading it since it relates to your problem and describes a good solution very well.

[Laurent]

It's not really ideal but I think it's fine, right? Or do you see any problems with that?

If you want a quick solution so that you can have fun with other parts of your code, it's probably fine.
If you want to learn the "right" way of doing things, for your future projects, that won't be enough.

[Jesper Juhl]

I really like the multi-thread idea but I've never worked with threads so that kind of scares me off a bit.

Good.
I'm my opinion you should generally stay away from threads if you don't *really* need them. Threads introduce a LOT of complexity and often cause hard to debug problems (especially if you are not experienced with them). They are also often not really needed.
Don't get me wrong, there certainly are use cases for threads and they should be used when they are the best tool for the job - sure. But they are just often overused by beginners who see them as a panacea to solve all their problems and these people then end up with a ton of headaches since threads turn out to be much harder than they imagined.
Use them if you must. Avoid them if you can. That would be my advice.

[smguyk]

This is how I am doing it now, a fixed timestep for the physics:

  sf::Clock deltaClock;
  sf::Time deltaTime;
  sf::Time timePerFrame = sf::seconds(1.f / 60.f);
  sf::Time timeSinceLastUpdate = sf::Time::Zero;

  while (window_->isOpen()) {

    deltaTime = deltaClock.restart();
    timeSinceLastUpdate += deltaTime;

    while (timeSinceLastUpdate > timePerFrame) {
      timeSinceLastUpdate -= timePerFrame;
      game_.processEvents();
      game_.update(timePerFrame);
    }

    game_.render();

  }

It's looking good to me and dragging the window around and whatnot all works well.

Now, that's the correct way to do it, right?

[zsbzsb]

You should handle events no matter what, so move the event handling outside of the event loop. 

Also what is the point of the deltaTime variable? Just write the following.

timeSinceLastUpdate += deltaClock.restart();

[smguyk]

You should handle events no matter what, so move the event handling outside of the event loop. 

Ah yes, you're right, thanks for noticing!

Also what is the point of the deltaTime variable? Just write the following.

timeSinceLastUpdate += deltaClock.restart();

True! It's a remnant of my old code I forgot to remove.

[zsbzsb]

One other thing I noticed, is there a reason your window variable is a pointer?

[Kamiz]

Sorry for refreshing, but i think i found better solution for this problem.
Just exclude events handling time in your delta. No need for fixed time step.

sf::Clock Clock;
float Time = 0;

while (Window.isOpen())
{
        handleEvents();
        Clock.restart();
        updateGame(Time);
        render();
        Time = Clock.getElapsedTime().asSeconds();
}