I'm writing a platformer and when I hit the roof, if the roof sprites y is set to 0, my player seems to zoom off the screen. However if I set y to 1, everything works great.
I'm using the pp-lib link which just builds off the sdk collision system. The collision response is slide.
This is how I'm creating the broken collision rect:
It’s certainly possible there is a bug in the SDK here somewhere, but it’s a bit difficult to tell what’s going on without seeing more code.
I created a simple example in an attempt to reproduce the issue, but it seems to work even when the top block sprite’s y value is set to 0.
One obvious difference is that the size and dimensions of my sprites, as well as the velocity of the moving sprite, are likely not exactly the same as yours. I’ve played around a bit with these values but haven’t been able to trigger the bug.
Can you see anything obviously different in this simple example compared to what’s going on in your game?
Thanks for that code, it helped a lot. This turned out to be a really fun (?) one to track down. The issue ending up being that while we were already accounting for floating point imprecision in the C collision code, it wasn't quite enough.
This caused your sprite, after the first collision with the wall, to end up overlapping with the collision sprite (by 0.000002 of a pixel!), so then when it starts to fall, the collision system was getting confused and snapping the sprite to the top of the collision box instead of below it.
It's amazing your game happened to hit this, especially in a reproducible way. I bet it has caused rare and hard-to-reproduce errors for other people too.
Now that I have finally figured out what was causing this, I should be able to implement a fix. (I can't say for sure just yet what SDK version it will land in.)
