You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is mentioned as a bullet point in #68 and i'm opening it here for better isolation.
As the collision solution implemented in the project currently is not as much escalable, i'm taking a shot on it. Talking with @Stephcraft over Discord, he gave me advice on the desired implementation, using a PhysicsEngine singleton to register and handle every collision check for every non-static Collider object. The reached design is as follows:
Creation of a new class, PhysicsEngine, as a singleton with read-only calls across the project, with the instance that can be stored in SideScroller for update() calls.
Creation of a Collider abstract class which stores some rudimentary shape data, like position and rotation, bit-masking for quick collision detection, collision data, and some common collision methods. During initialization, it will register itself into the PhysicsEngine singleton, and un-register during destruction.
The collision calculations would be made inside each interested collider, as there could be many different collider shapes and collision logic depending of the concrete implementations.
Each class interested in having collision detection would need to store a concrete Collider object or list of objects, and move it along with them (as there is no common transform to move it automatically).
Switching the commonly used collision logic of non-static objects into these classes, and delegating the pre-calculation of collision data to the PhysicsEngine class, such as each interested class that stores a concrete Collider class can quickly access to the collision information stored in each of them (All colliders colliding and collision normals).
The PhysicsEngine will do some pre-calculations for each shape defining some grid-based bounding for quick collision detection (filtering the Colliders by distance). These bounds would be stored inside the Collider and recalculated each time it moves inside or outside a cell, to avoid unnecesary processing.
Tile-based collision data would be supported as it is now implemented, so it wouldn't be necessary to define a new Collider for each tile present in the scene.
Things left out from this refactor, left pending of implementation:
Other collider shapes beyond the standard RectCollider.
Collider shape truncation, so it isn't necessary to calculate for each of its bounds.
(Possibly) collision detection for rotated shapes.
Please, do tell me if i'm missing something or any suggestion, i'll be working on it shortly.
The text was updated successfully, but these errors were encountered:
I once tried to integrate the fisica library into the Project, although I came across some kind of glitch with the library and abandoned it.
It might also be worth looking at Box2D for Processing to see whether that could be integrated, before designing a new collision/physics engine in-house.
This issue is mentioned as a bullet point in #68 and i'm opening it here for better isolation.
As the collision solution implemented in the project currently is not as much escalable, i'm taking a shot on it. Talking with @Stephcraft over Discord, he gave me advice on the desired implementation, using a PhysicsEngine singleton to register and handle every collision check for every non-static Collider object. The reached design is as follows:
Things left out from this refactor, left pending of implementation:
Please, do tell me if i'm missing something or any suggestion, i'll be working on it shortly.
The text was updated successfully, but these errors were encountered: