hexus / phaser-arcade-slopes

:triangular_ruler: A Phaser CE plugin that brings sloped tile collision handling to the Arcade Physics engine
MIT License
126 stars 16 forks source link

Sprite jitters/bounces at some tile junctions #55

Closed SHG42 closed 3 years ago

SHG42 commented 3 years ago

Here's a minimal example that reproduces the behavior. Screen-recording the jitter in action didn't work out, but here's two screenshots showing two instances of the tile junctions where it happens. What could be causing this? jitter1 jitter2

hexus commented 3 years ago

Having a quick look over your code, I think it might be to do with how these features are being used:

// Prefer the minimum Y offset for this physics body
hero.body.slopes.preferY = true;
// Pull the player into downwards collisions with a velocity of 50
hero.body.slopes.pullDown = 50;

Try toggling these on and off, as well as reducing the pullDown. Honestly, I implemented the pull features quite experimentally , hoping they'd help me keep my physics bodies sticking to slopes, but I didn't end up using it.

Another thing to try: Filling in the missing tiles underneath the ones you're colliding with. This will disable more potential collision normals that could be getting greedy here.

Really strange that it only happens in this particular spot on your tilemap, too! 🧐

SHG42 commented 3 years ago

Hi, thanks for getting back to me! I had already tried fiddling with those two settings (toggling one then the other, toggling both, etc\0, and while decreasing the pullDown reduces the bounce slightly, it doesn't eliminate the bounce. As for the tiles, while the debug graphic doesn't show it, those tiles are indeed already filled in, as seen in this Tiled screenshot: map_nodebug

hexus commented 3 years ago

Hmm, really weird. I'm going to have to clone down your project and debug this one then, I think. It may be an edge case (pun intended) that I missed with the heuristics used to resolve these collisions.

It's been a while since I've developed this project and haven't been intending to maintain it due to Phaser 3 & 4, but I'll try to find time. Very busy in my full time work at the moment. 😄

Are you only facing this issue with the half-tile (22.5 deg) slopes?

SHG42 commented 3 years ago

I'm finding this problem with other tiles, too. The example I provided is derived from a larger project. I'll go over the levels in the full-scale project and find as many of the other cases as I can, and I'll come back here with screenshots.

SHG42 commented 3 years ago

Okay, I went through each level in the full project and screenshotted every instance of sprite jitter I could find, as seen here. I could have sworn I saw it happen before with the horizontal half-tile, but not this time. I zoomed in so that the red markers are more clearly visible, since it's not the same markers in all instances.

hexus commented 3 years ago

These are quite helpful thank you! The red markers denote the axes for which collisions are being ignored, to prevent unwanted "jagged" collisions between tiles, and these screenshots show different cases where this is going wrong. The giveaway is indeed the asymmetric differences shown in your screenshots, where the tiles on the left have an arrow pointing upwards. In theory, this should work so that only one of the tiles is pushing other physics bodies upwards, but something isn't quite right in the resolution.

Thanks for the further examples. Love the artwork, too, by the way!

One more thing to try might be switching to 32x32px tiles, and seeing if the same problems occur; I almost exclusively tested with this tile size. Scratch that, I can reproduce it in 32x32.

hexus commented 3 years ago

I've found the root cause I'm trying to settle on the most appropriate fix. 👍

hexus commented 3 years ago

@SHG42, if you could try the following build, let me know if it alleviates some of your issues:

The issue is with the heuristic algorithm I devised to ignore certain collision axes with certain neighbouring tile configurations. I've tweaked this algorithm to ignore these normals in a few less cases. This should fix the simple case presented in your demo, but possibly not all the cases in each screenshot (which I'm yet to reproduce all of).

If this fix is adequate for some of your cases, and doesn't make any other collisions worse all of a sudden, I'll release it as 0.3.2.

hexus commented 3 years ago

I've just realised even this fix still won't cover all of the quarter slope cases, but I'll continue to investigate this when I get the time.

hexus commented 3 years ago

I seem to be on track with some of the intricate tile configurations you've shared:

image

image

image

Here's one that I'm still working on:

image

There's also a separate undesirable collision resolution issue I've discovered, unrelated to tile configurations or these kinds of ignored collision normals, but I'm hoping this won't affect your usage.

hexus commented 3 years ago

Please try the build here and let me know how you get on:

SHG42 commented 3 years ago

Thanks for the updates and for taking the time to work on this! I will test this and let you know how it goes.

SHG42 commented 3 years ago

Holy moly, it's fixed! Thank you so much!

hexus commented 3 years ago

Nice one, you're most welcome!

There are definitely some oddities I'm finding with how a couple of types of collisions resolve still, and I may work them out at some point, but for now I'm happy with that simple improvement from what I learned building Phaser Slopes for Phaser 3.

Thanks again for the super clear reproduction, it made addressing the issue much more straightforward. 🌟

I'll release this as 0.3.2. Cheers, and best of luck with your project!