Alright, I think I got it. As you can see in this image, whenever you highlight the entire area of the images is much larger than they appear, which is why the collision is being bad. (Here you can see the image in an image editor, clearly a square. ) The problem, as far as I can see (I cannot speak German so I'm sorry if I'm misinterpreting the code) is that the Kollision check always returns true, even if it is touching an invisible pixel. You could fix this by doing something like changing the objects to ensure that they are all squares, or you could implement the greenfoot code I mentioned earlier. I made an example using the Pixels to determine collision , you should try it and see if it fixes your problem.

I will say, using the example I made, while easy, is very resource straining on a computer. It's generally better practice to make your objects all rectangles and then using getOneIntersectingObject() or some other method.

okay, thank you so much !! the pixel based method is insanely accurate, but I see what you meant with slowing down the computer... so if I break the obstacles up into rectangles and center them in the file is the hitbox then also centered?

I think the blue colored area is square because of the app I made them with. you always have a square base area to paint on. But if I did understand it right the hitbox might be centered In this base area

So the entire image is the hitbox area, and since the image has a bunch of open area, the hitbox has a bunch of invisible open area. But yes, if you were to break them all up into rectangles (like this) , and then center them, ensuring that the edges of the image were right at the end of the obstacle, it would correctly work. It will require a bit more work from you, but it will do what you want, and hopefully not lag out your computer.

I guess I can adjust the size of the hitbox with get width/ get size ? even if not, you have really really helped me, so thank you for that !