Edit: I solved this problem, check the devshed forum (linked below) for solution.
I am trying to write a crude game engine inspired by spritesheet animations but I'm having a problem.
I need help on a hit test.. I wrote earlier a function that works WONDERFULLY with hitting squares and telling you which side the square is being hit from and returns a value so the object could bounce away. And also wrote one with circles. (See http://omz-software.com/pythonista/forums/discussion/138/crude-hittest#Item_4) But I'm having a hell of a time with rectangles!
I wrote a thread on python forums over at devshed: http://forums.devshed.com/python-programming-11/rectangle-hit-test-937964.html
Aside from what I said in that thread, here is the project I'm working on: https://gist.github.com/278158f70872b37f70df
Please note the project is VERY messy and has some stuff I plan on deleting. It's also using a prototype sprite walk function made on these forums (http://omz-software.com/pythonista/forums/discussion/77/spritesheet-animations) But if you want to see and test my hit test function it's a good place to start. The hit test itself is on lines 77-106 and the reaction to the hittest (by the green box) is on lines 278-285 if you want to mess around.
What I need is help figuring out how to make a hit test work on two rectangular shaped objects. I want the function to return a value, between 1 and 4, representing which side object1 is being hit. It is deceptively simple and I'm sure a skilled programmer or mathematician will see the obvious solution while I'm just pounding my head against a table..
Thanks for any help!
What if multiple sides are hit, like this?
That was in fact the problem I was having, since in ALL hit tests at least two sides are being hit. Originally I just used the origins of both boxes to find out which side is more important, but with rectangles the old solution didn't work.
I solved this using two methods. Method 1: It checks to see if two corners of box1 are inside of box2, in which case it knows thats the side it's hit. If there's only 1 corner inside box2, then it proceeds to Method 2, my old hittest.
Method 2: Calculates differences between origins. So if dify is larger than difx, it knows that the hit is either top or bottom.
By combining these two methods, it works fine on both the center of the object AND on corners like you depicted above. Since the problem was due to large rectangles (my level walls) hitting a small box (my level's character) this solution works wonderfully.
This also leaves the window open if later on I want the hit test to return information like Top-right or bottom-left instead of just the four cardinal directions.
However, if one needle-thin rectangle interacts with another needle-thin rectangle, I am not sure if my hit test would work properly. It's worth testing out.
I wonder whether doing the hit test based on colour of objects might be better after a certain level complexity? That way you could have arbitrarily shaped obstacles? (But larger memory use )
I wouldn't mind experimenting with that. Then you could have levels drawn by random noise or image sheets, which could be useful depending on what you're designing.
But I don't know exactly where to begin searching for the color of x,y on the screen.
As for larger memory use... if there's an easy way to search for color x,y then the memory shouldn't be much higher.. since you only need to do a hit test for 1 pixel per object being tested. You don't need to test the entire screen... unless the background itself is dynamically moving and colliding.
No I couldn't find a pixel colour test :(
Lol @ "dynamically moving and colliding" background ! - I have enough trouble with rectangles!! ;)