# High level overview when handling collision detection (or resolution) with overlapping when already touching

I'm looking for some advice on handling collision detection when you've already collided (at a high level).

Suppose we're using 32-bit floating points, but with the constraint that the entire level is in some small range (say +/- 1000.0f from the origin) and for the sake of this topic, we assume the epsilon checking is robust... at least until later on in this post.

In our imaginary world, an AABB moves along and is detected to collide with another line. This is using exact collision values, so collision resolution occurs and leaves them touching like one of these below (borrowed this from google, assume only one box B is in the image):

On the next game tick when moving, the way I do collision detection is using less/greater than equals, instead of something like less than, so the boxes in the above image will consider a collision to have occurred even if moving away from the center box.

After doing some research, someone suggested that upon a collision detection, to move it back by some small unit (0.001f) so that you leave the 'overlapping case' to only occur when you have truly collided with the line, and if you do collide then you are moved slightly back so the collision detection checks would return false if checking again. This has it's own drawbacks but that is another discussion.

Then I thought about what would happen when you want to slide along a wall. My worry is that if the body is going to slide along the wall, I will get a bounce effect on some angles if the player is facing the wall and trying to run into it while their velocity is sliding them along the wall.

Since I'm using exact collision times, then that means if I'm facing something like 0.01 degrees away from a the wall while running along it, I will have the AABB move inside the "push it out on collision detection" range and actually colliding distance, as seen in the image below:

Colors:

Blue: The player AABB

Black: The walls

Green: The resulting vector after hitting the wall

Red: Same direction as the green one, using it to make an angle comparison with the pink line

Pink: The possible direction a player could have their player facing

Now my worry is that the pink vector could be taken such that it moves the player inside that small "epsilon to push back from the wall" space (as seen by the gap between the blue and black box, not to scale of course), and then every game tick, there would be a jitter, example:

Tick 0: Player moves inside the epsilon limit but doesn't touch the wall, so there's no collision

Tick 1: Player touches the wall, moved out by 0.001f from the wall

Tick 2: No collision but the player moves closer than 0.001f to the wall (ex: the player is 0.000042f from the wall)

Tick 3: Player touches the wall, moved out by 0.001f from the wall

... etc (basically tick n and n + 1 repeat)

I am worried about jittering happening in this case where every two ticks, the player is moved out from the wall. When I play other games, I don't notice such things happening... however there is one game I play that it stops you before hitting the wall, but if you keep running at it for a second or so then you move slightly closer... but this may or may not be a bug in that game. I'm not sure if other games do something different or somehow fudge numbers and/or account for this somehow so that no such things happen.

There are a few thoughts that I have on this:

• Maybe the small value being pushed out is so insignificant that it wouldn't be noticed when rendering? Maybe the angle to which to trigger it is so small that it's just not worth wasting time over or complicating code for it?

• Is it worth tracking "what was touching last frame" and then doing some basic math to see if the new movement vector is parallel or away from

• Maybe similar to the above but instead doing a check of all the close-by lines in the narrow-phase checks for "touching" and deciding what to do from there? Though this adds extra code and computation and I'd like to avoid that because I have a heavy focus on speed due to being CPU bound.

What do other games do? What do you do? Any thoughts or recommendations from a high level? I value simplicity of code, so the cleanest solution is best for right now.

Note that collisions don't need to be perfect (or else I would have chose a double over a float, as I want the speed from vectorization instructions), however I'd much rather do it the "right" way first rather than a wrong way that I have to throw out.

Further, the code that exists for lines/vertices/segments/sweeps all work for exact collision times; I have access to the exact time t that an AABB collides with another AABB or line segment.

Lastly, assume wall collisions are a common occurrence in the game, as this also applies to floors/ceilings, not just the walls (this is 3D, but I'm looking at this from a 2D perspective for now as moving it to 3D is not much harder).