ARCADE physics overlap issue

[hongping]

I am using ARCADE game physics, and enabling the overlapping of two sprites by

 this.game.physics.arcade.overlap(this.rat,this.cheese,this.eatCheese,null,this);

But, when running the game with body debug, it showed that the function is called even when the two sprites are not overlapping. How to solve this?

 

[lewster32]

Hard to say from this - uploading your current version would definitely help.

[hongping]

Hard to say from this - uploading your current version would definitely help.

 

I am using Phaser 2.1.2

[lewster32]

Sorry, I mean actually uploading your game in its current state so we can see what's happening.

[hongping]

I created a Codepen here
http://codepen.io/hongping/pen/HguAq

 

It can be seen that before both body collide, it will go into the collide handler.

 

Please help!

[lewster32]

Okay I see what's happening now - this is normal behaviour. What's happening is that the physics simulation is run directly before the frame is rendered, but still within the same frame. This isn't normally a problem unless you block code execution with an alert, as the frame is rendered directly after physics has been calculated. Try using a non-blocking method of displaying the collisions, such as console.log("HIT") or something, and you'll see that the collisions happen during the same frame that the sprite bodies visually collide.

[hongping]

I create another Codepen to better show the real problem I am seeing.

 

http://codepen.io/hongping/pen/lrabo

 

Ideally OBJA (the moving OBJ) will not hit OBJB. But, they still collide and making OBJB killed.

[hongping]

I create another Codepen to better show the real problem I am seeing.

 

http://codepen.io/hongping/pen/lrabo

 

Ideally OBJA (the moving OBJ) will not hit OBJB. But, they still collide and making OBJB killed.

 

BTW, this happened intermittently... 

[lewster32]

So you want an object to be deflected before it hits another object? In this case you need to detect proximity rather than an actual collision I'd imagine? Something like this would be a simplistic solution, though it's very framerate dependent: http://codepen.io/lewster32/pen/DFzkq

[hongping]

So you want an object to be deflected before it hits another object? In this case you need to detect proximity rather than an actual collision I'd imagine? Something like this would be a simplistic solution, though it's very framerate dependent: http://codepen.io/lewster32/pen/DFzkq

 

Found this when implementing a scenario that the user just deflect before hitting the object. I can see from the display the player and the object are not overlapping, but still, the object get killed, Hence I recreate the movement here. Will try to add the code as you suggested.

 

But I am wondering, are there solutions which are not dependent on framerate? Or, can I create the solution based on the worst case? I try having slower X velocity, the problem will occur less, but that's only avoiding the problem. 

[lewster32]

What's really needed is a 'trigger' body larger than the 'kill' body, so two bodies on each sprite, but you can't really do this in Phaser easily. It's a tricky problem actually, moreso than it seems and definitely more than it really should be! I'd be interested to hear someone else's possible solution.

[MichaelD]

If I understand the problem correctly you could calculate where the objects will "meet" since velocity and direction is known, you could calculate in which x/y they will collide and plan accordingly based on their current possition.

That ofcourse will take a performance toll if there are many objects that need to calculate their possition with one another.

 

One other solution would be to add "white space" (like a transparent block) in front (or any other direction) of the objects so that the "White space" collides earlier than the object that is actually shown. In order to capture the event.

 

After seeing lewster32's proposition I would think that if two objects are added to a group one "fake transparent collition block" and one "real collition sprite" and maybe you can check collition on both of them with different things to do to each case