Pixel-perfect collision detection can be implemented either by scanning overlapping pixels between two images at run time (this can even be done on a GPU), or generating geometry that fits the artwork perfectly and colliding that geometry instead of checking pixels each frame. Pixel-perfect collision detection as you're asking for it is not trivial to implement with good performance in mind, even though your use case may simple enough that performance scaling doesn't matter to you.Matter.js is complex enough that we wouldn't want to change its behaviour other than for optimisation.Arcade physics was designed to be simple and fast.While it might be possible to implement pixel-perfect collision detection as part of Phaser, here are some of the main reasons I can think of that it hasn't been done yet: While neither of these were trivial, I can imagine a plugin that implements pixel-perfect collision checks in a similar way. This is why choosing the right physics engine for a game is such an important decision, unless you're willing to write your own abstraction for your own needs (I have done this in one of my own projects).Īll of that said, even I've written plugins that augment how collision detection and responses work in both engines. While I agree that it would be nice for Phaser to offer a common API across both, there's only so far something like this can go before you start needing to delve into the specifics of each engine. Matter has many more capabilities, and as a result is more expensive CPU-wise, with a bigger API surface. This allows its collision detection and resolution to be very fast, because it can make a lot of assumptions about particular shapes and use dedicated routines for those shapes. No rotation and no complex shapes, only rectangle and circle intersections. I see it referenced here and here, but where is the main logic for how the sprite's body is determined? □Ī physics engine handles collision detection and responses between physics bodies, which indeed means calculating whether they've collided at all, not just what to do after they have.Īrcade, specifically, is a simple physics engine by design. I was trying to dig through the code to see how the ".body" property was created for sprites, and couldn't really find it. Yes, although I don't know much about how Phaser works under the hood. Note: I may be using the wrong term "Sprite" here where possibly I mean "GameObject" since I would expect this feature to be true for any collidable thing regardless of whether it is animatable or not.ĭo you want to help provide this feature? I think this would be a great feature Phaser if it doens't already exist! Is this currently possible and I'm just not aware of the api? (I asked about this in a forum post here and naively assumed the lack of an answer meant it wasn't really possible with the current api). Is it especially difficult or inefficient to look access the transparency of the image and generate the physics body this way? To me it seems obvious that it should be like this so i am wondering why it is not the default. The advantage of this is that there will be pixel-perfect collision detection between sprites. I am proposing that the physics body be generated by ONLY the non-transparent pixels of the image. The physics "body" that is created from this is the bounding rectangle of the ball which makes collision detection pretty wonky.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |