Jump to content

ARCADE physics overlap issue


hongping
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...