8 direction - sliding stuck when using small sprites

[Ldwebster111]

Problem description

When the new sliding option is checked, the size of the sprite can have an impact on whether a sprite gets stuck or not.

sticky sliding.zip

Steps to reproduce

1. start project and move the player sprite down (behaviour as expected)
2. press space to switch to the smaller sprite
3. repeat the movement (sprite becomes sticky)

Observed result

When the player is a smaller sprite, it has a tendency to get caught on corners that would not stop it as a larger sprite. Additionally, the stickiness is not always consistent, sometimes it will prevent the sprite from moving completely, other times it will create a little stutter but the sprite will keep going (like in the very last spike in the gif above)

Expected result

Movement should be consistent regardless of player bounding box size.

More details

Previously, I was using a completely different method to handle sliding movement in my game, but with the latest stable build I noticed that something had changed so that 8 direction was producing a stuttering effect when colliding with my sloped walls (despite them not using solids). As such, I decided to test out the new sliding behaviour and, while it looks pretty good, there's noticeable areas in my game where my small player sprite is getting caught on corners.

Affected browsers/platforms:

Chrome (stable), Firefox (beta)

System details

Ryzen 3600x Win 10 16gb

[Ldwebster111]

This is happening on square collisions too:

While it seems to happen at any speed, it's more noticeable when the sprite is going faster (as it's more jarring). Only noticed this in-game when I was sprinting around the level. It might be a bit difficult to tell in that gif ^ but the larger sprite is not getting stuck on the corners while the small one is (though not stuck enough to stop it's momentum completely, unlike the spikes in the first gif).

[Ldwebster111]

Framerate has a big impact on this.

Low frames make it a lot more noticeable:

high frames no so much. Plus, running in unlimited frames completely removes the issue (obviously not a viable solution:

[AshleyScirra]

The collision algorithms involved are extremely complicated and hard to make bulletproof in all possible circumstances.

In some circumstances the collision algorithms will try to do "move a small distance and check if it collides there". Defining "a small distance" is tricky. Previously the Platform behavior used an absolute value, e.g. 3px. The problem with that is then some people go and make tiny games where the player is only 2px big, and then that distance is far too large relative to the size of the player, and collisions act weirdly.

To avoid that type of problem, the 8 direction sliding mode does indeed use the size of the object as a guide for how far to move in some cases. It takes a fraction of the average size of the width and height of the object. This approach fixed a prior reported problem #5777 where the player was tiny (only 9 x 12) and generally seemed like a more robust approach. However as you've observed it does mean the size of the object can have an impact on the way collisions are handled.

I don't know of a better way to handle this, other than adding some obscure settings that will be extremely difficult to explain, which I'd rather not do.

[F3der1co]

@AshleyScirra
I just wanted to state that this issue comes up regularly on the community discord. So I wish there was some way to solve this, like limiting the step size so it doesn't become too small, the workaround of making the sprite larger and the collision polygon smaller fixes the issue in all cases I have seen, so the fix of having a minimum step size should work unless I am missing something

[F3der1co]

Also IMO this issue is worse then #5777 was, as this one happens in a lot more common collision cases. So personally I would rather lean a bit more towards avoiding this one than the other one.