Testing where a collision occurs on an object

.CAPX here: sugarsync.com/pf/D6025908_4317202_6583129

I have pretty much the same set-up that Ashley has in his tutorial, but there's one tiny little discrepancy...

In my .capx the box sprite (the one with the "evil" eyes...aka Dr Box), the collision polygon is uniform with his box shape (minus the eyes). I have it set where if MrStick is falling and collides with DrBox, then DrBox will flash and MrStick will take no damage (represented by the health meter in the top-left).

If MrStick is on the ground/not falling and collides with DrBox from the side, then MrStick takes damage. HOWEVER! It should be possible to take damage even if MrStick is falling and still collides with DrBox from the side - not on top.

I tried setting up a comparison of X values between DrBox's origin coordinates and MrStick's, citing that if MrStick.X was within DrBox.X(+/-)50 (pixels), regardless of jumping or not, to determine if MrStick was colliding with DrBox from the side or the top. (But I've since deleted that line.)

Is there a better way to test what side or point of a collision polygon is hit?

compare the Y of them, the height instead of their horizontal whereabouts might be more applicable?

so (this is without looking at your capx and assuming both have origin points in the middle)

system - compare two values -

> (mrstick.y + mrstick.height/2) is less than (drbox.y - drbox.height/2)

        > no damage taken

> (mrstick.y + mrstick.height/2) is greater than (drbox.y - drbox.height/2

        > damage taken

• plus half his height to give the y of where the bottom of mrstick is, so if his feet are higher than the top of drbox - no damage, if his feet are lower (greater in y) than the top of drbox than he can take damage.. adjust as needed

*** if i've mixed up the up and down of the y axis just switch the plus and minus signs.

wretchedshark - Thank you, sir. I believe I had a similar idea but opted for the horizontal (X value) option instead. I suppose either way will work. I'll test your method, though.

When you have the .height/2, is that because you are assuming that the origin points are dead center for both X and Y values? Presently, I have the origin points at the bottom middle of both sprite characters (so, at their feet, basically).

For my case, given the location of the origin points, I would probably have to amend the code to MrStick.height <greater/less than> DrBox.y+50 pixels (or however tall he is).

...I'm probably expecting a more complicated solution and having trouble finding an easier one...when it really IS that easy. Off to test things! THank you again!

Rhindon - yes it is because of that, but only the Y is dead centre (since this is not using X).

using the height seems the simpler of the two to put into effect. you could use x, just setting similar margins to the sides of both sprites and testing for when the player.x (plus margins) is on the x of the drbox/enemy.x plus margins. just seems a tad fiddly in my mind.

i would advise not using a set number of pixels to add though (DrBox.y+50 pixels) and instead something that will change with your characters (should you choose to change their height).

it is not necessary of course but will save a lot of tedium in case you decide your character is too big or small. or for copying and pasting bits of code to apply to other sprites (which i do a lot). and, as i was advised, if you do code something like a characters attack range versus a lot of enemies (for example) if you have to go back and change that in all the code (instead of setting an instance variable for range) it would again be tedious.

(drbox.y - drbox.height) - instead of (drbox.y - drbox.height/2)

• this is assuming the origin point is at the very base of the sprite image

wretchedshark - VERY good points. This is just to work SOMEthing out to begin with, but I'll keep that in mind. ONE thought JUST occurred to me, though. IMAGE POINTS! Right NOW, I've only got one frame for DrBox. I could set multiple image points as the range of detection! So test if the collision happens closer to I.P. #1 and 2 OR I.P. #3 and 4. Something like that. So if the Y value of MrStick's origin point is between DrBox's Y values of image points 1 and 2, for example, and the X value is one the correlating side, then...HIT. I'll work it out.

It might prove to be tedious, but it'll perhaps account for any changes in the size of the frames/images. What do you think? Does that make sense?

Rhindon - i'm not sure about other game types, the tutorials advise in platformer's for your player at least to have an invisible player box with the platform behaviour, and working as your collision mask, and then sticking your animation on top of that box with either pin or set position (i'm not sure which is better, if either is even).

the reason i mention this is it follows the same principle, you can change your animations but your actual player (invisible under box) remains unchanged and therefore always interacts with the environment in a consistant manner.

you could use image points to attach other invisible hitsensors and use that instead of the x and the y of the sprite's to weed out even further changes.

(again i'm not sure which is the "better" approach pinning or setting a position), you could just make sure that it's there - by pin or set position - and then on collision or on overlapping the to-be invisible hit sensor take damage. if you change the sprites size later on you'll just have to change the image points and the hit sensor sizes instead of the code.

it's not that big of a deal either way, just something to think about   <img src="smileys/smiley1.gif" border="0" align="middle" />

wretchedshark - I hear ya. Since this is just a test game - one that might see its day as an intentional app - I'm not worrying too much about it in DrBox's case. I'll definitely implement the hidden sprite with Platform behavior when that time comes, of course. For now I was just trying to work out hit detection. I deeply appreciate your feedback, though. Thank you! :D