Static engine: "Bounciness" issues

[ELCGames]

So far, everything in my static engine is working just fine. All the detectors are staying in place, wall detection works fine, X movement is working great, but I've come across a problem. The player will never get "stuck" in the wall, but there are some annoyances with when the player's movement is getting corrected that I'd really like to fix.

When the player collides with the wall, sometimes, there's an annoying bit where the mask is temporarily in the wall, and then shoved back out. This probably wouldn't be as much of a problem with fastlooping, but I'm still wondering if there's a fix for this in it's current form.

Here's a link to the engine, if you want to give it a look. It's commented and organized fairly well, so hopefully it shouldn't be too difficult to sift through.

[Konidias]

I believe the reason this is happening is simply because you're movement speed is far greater than your correction speed. What's happening is that in one loop, your object is jumping 5 pixels (into the obstacle) then you're setting movement speed to 0. (so it doesn't go any farther) and then you're subtracting/adding 1 to the position. So it's going to still be 4 pixels in the obstacle at the end of the loop.

You need to set it up so that it's totally out of the obstacle by the end of the one loop. But even with that, you may end up with issues.

Is there a reason you're not using fastloops?

[ELCGames]

I just wanted to give it a shot, I suppose. The problem with fastloop movement, for me at least, is that I haven't properly learned how to do slopes yet.

[Nifflas]

I have a widget on my website for this that demonstrates what I think is the most convenient way to do this, check my signature and look for the platform movement widget.

The key is, for every pixel you're moving the object horizontally, you need to test if the object overlaps with the background if it's located one pixel up, at the original location, one pixel down, and two pixels down. You can store it in 4 variables, let's call them A,B,C,D.

If B overlaps and A doesn't, it's an up slope. Move the player one pixel up.

If D overlaps but C doesn't, it's a down slope. Move the player one pixel down (if D doesn't overlap either, it's a free fall, in which case nothing should happen).

If B overlaps, and C doesn't, the player being pushed down by a slope in the roof. Move the player one pixel down.

If A, B, and C overlaps, it's a wall. Collide.

[ELCGames]

Thanks for that explanation, Nifflas. I'm going to try this out.

I also find it amazing how you've managed to do this without any detectors at all. I suppose it really saves some valuable file-size.