Collisions when using animations

[Andles]

I have an animation; its basically a small square that becomes a taller rectangle over several frames (a spike growing and shrinking).

 

I have a player sprite too, and this is meant to dodge the spike animation.

 

My problem is that the collision occurs even when my player passes safely over the top of the spike (the animation in its small square frame).

 

So it seems that the animation sprite will collide with my player simply because one of its frames (even though currently not reached) would be big enough to cause a collision with my player? What I want is for my player to dodge the animation in its small state and only to collide when the spike pops up further.

 

Using arcade physics animation, and a sprite sheet through JSONHash (texture packer).

 

 

update: function () {

this.physics.arcade.collide(this.bird, this.spike, this.collider, null, this);

},


collider: function () {

alert("collided!!!");
 

} 

[drhayes]

Your sprites are colliding because the bodies of both of your sprites collided. Phaser doesn't look at the animation frame to determine collision.

 

The parameter after "this.collider" in your example code is the "processCallback". If you pass in this function then collision only happens when it returns true. You could check the current animation frame of your spike sprite in there against the position of the player and see if they're colliding per your animation frame.

[mwatt]

I'll throw in 2 cents here too.  I have a game where one common type of object positioning was controlled by me setting it explicitly in the update function.  Since in this case, positioning isn't physics-driven, I handle these collision detections myself, starting with something like this:

if (Phaser.Rectangle.intersects(spriteBoundsA, spriteBoundsB))

 

That however, yields a lot of collisions that don't really look like they ought to be collisions.  This is no doubt due in part to the fact that my sprites are spheres and I'm collision checking with squares.  There may also be something with the collision check code being not exactly in sync with the timing of the position reset... I'm not sure on this part.  Anyway, what I did to get around this is treat the check above as a kind of "pre-qualifer" for collisions.  If that check returns true, I check once again, right away, with slightly smaller squares.  If that one passes the test, I call it a collision.  For whatever reason, this works fairly well, though not perfectly.

 

I don't know if this will help, but perhaps it will be of some value to you.

[Andles]

Thanks both, valuable insight.

 

I had in fact already used the processCallback approach, which works well. I posted the question because it seemed like I was going the wrong about it, apparently not.

 

As it happens, I don't think I need to be using physics at all, so might experiment a bit and see which performs best.