1
\$\begingroup\$

I have the following game loop :

while true {
    HandleInput()
    Update()
        PhysicsEngine.HandleCollisions()
        PhysicsEngine.Integrate()
    Render()
}

For now, HandleCollisions is simply negating the velocity vector of the player. The problem is that if I hold the button to walk forward this results in a jittery screen flashing between the render of the forward walk and the backward walk. How can I smooth it out so that it feels like the player has stopped even if I am still pressing the button ?

From what I have found on the internet, Unity's Rigidbody.MovePosition solves this problem, but I was not able to find its implementation online.

One thing that I thought about, but am not sure if it is the solution is the following.

  1. Find distance of penetration in the HandleCollisions function
  2. In the same function move object this much
  3. Change velocity to (0,0,0)

The problem here is that from my understanding the Integration step should be the one doing the movement and I should only be changing velocity. If that is correct, then I have no idea how to solve it.

edit : removed architecture tag

\$\endgroup\$
1
\$\begingroup\$

Without knowing specifically what your two physics functions do, I suggest checking for the collision first before moving your player.

Consider the following example:

  • Move player.x by 1
  • Physics check
  • Move player.x by -1
  • Result: flicker

As compared to

  • Physics check with potential movement (player.x + 1)
  • Realise that there is a collision
  • Set players velocity to 0
  • Result: no flicker.

In the second case, since you are predicting if the player will collide with the wall before moving the player, there is no longer a need to push the player back, hence eliminating the flicker.

\$\endgroup\$
  • \$\begingroup\$ ty for the reply, the Integrate function does just that. position += velocity * deltaTime. The HandleCollisions simply negates the velocity of the object if it is colliding with something. As to what you said after, I am indeed checking the collisions before I integrate. \$\endgroup\$ – Martin Spasov Sep 29 '18 at 6:15
  • \$\begingroup\$ In that case, you just have to further debug to find out what is causing your animation to switch states. Which value is your animator referencing to decide to switch states? \$\endgroup\$ – eclmist Sep 29 '18 at 7:58
  • \$\begingroup\$ I do not have animations implemented yet so I don't think that this is related to my problem. These are the steps that the program takes 1. HandleInput - sets a bunch of bools if the buttons are pressed 2. Update - sets the velocity of the objects based on the bools set in the previous step 3. HandleCollisions - checks if there are any overlapping objects and if so, it negates the velocity 4. Integrate - adds the velocity * deltaTime to the position 5. Render 6. Start at step 1 \$\endgroup\$ – Martin Spasov Sep 29 '18 at 8:48
  • \$\begingroup\$ The problem is the fact that with the button pressed it means that on iteration X of HandleCollisions we have negative velocity and during the same iteration we push back the object during the integration step. On iteration X+1 the button is still pressed and so we set the velocity back to positive, we HandleCollisions but this time there are no collisions and so we move forward again. This becomes a loop and we go back to iteration X \$\endgroup\$ – Martin Spasov Sep 29 '18 at 8:49
  • 1
    \$\begingroup\$ How did you end up with negative velocity? \$\endgroup\$ – eclmist Sep 29 '18 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.