Replies: 4 comments
-
as I was saying on gitter, as a simple improvements, what about skipping objects with the WORLD_SHAPE type from the container update/draw loop ? |
Beta Was this translation helpful? Give feedback.
-
It's required for |
Beta Was this translation helpful? Give feedback.
-
i was thinking about this, and I'm wondering if it's actually a good idea. Considering that the quadtree is a rectangle based algorithm, and therefore relies on shapes bounding box, this could generate collision check with the (one) collision shape at every movement, as if the collision layer is complex there is chance that the bounding box would then take the whole level. keeping the current implementation for sure create more shapes, but allow for less collision check per frame ? and I suppose that ultimately the trade off is for the end user to optimize the number of collision shapes he is creating. (last but not least, with entities objects not being currently pooled by default, none of these collision shapes are being reused from one level to the other, which keeps the GC busy when changing level) |
Beta Was this translation helpful? Give feedback.
-
Suppose shapes are added to QuadTree instead of entities. This was how I originally envisioned the QuadTree would be used. The entity bounds can still be used to lookup candidate collision pairs within the QuadTree. But what you'll get back is individual shapes, instead of an entity who references a body who references all of its shapes. |
Beta Was this translation helpful? Give feedback.
-
Each shape in the collision layer gets its own entity and body. This can get fairly heavy with enough shapes on the map. Optimize by squashing all shapes in the collision layer into a single entity/body.
Beta Was this translation helpful? Give feedback.
All reactions