This is a proposal for some changes to the hitbox/collision-detection system, for the purpose of improving efficiency and interoperability with other parts of Flame. This issue is intended as discussion / collaboration with @spydon, before we start the actual work.

First problem that needs to be addressed is that currently the collision detection system can only "live" at the root FlameGame level, which is not always optimal. In a more complicated game the game world can be several levels deep in the component tree, or there could be several worlds (say, for each level). So, I suggest then to

• implement a mixin similar to HasCollisionDetection, but which could be applied to any Component.
  • This could (in theory) be as easy as changing the on part of the current mixin.

Second problem is that the current implementation of ShapeHitbox is based on ShapeComponents, not on Shapes. Thus, we need to

• create Hitboxes based on Shape class and its descendants.
  • The API of both classes is quite similar already.
  • This would allow us to test for intersections more efficiently (the Shape class has support for intersection detection of convex shapes).
    • In order to take advantage of this algorithm, we'd need to change the API of the current intersections() method; or, rather, create a second more efficient method and deprecate the first. The signature of the new method would be Intersection? intersection(T other);, which is to say it returns null if the two shapes do not intersection, or an Intersection object if they do. The Intersection object can then be queried for the intersection points, or some other intersection properties. However, if the user is not interested in the intersection points - then that calculation can be skipped.
      • the Intersection class could also contain references to the hitboxes + components that are colliding.
      • note that currently Hitbox class is defined as implements GenericCollisionsCallbacks<T>, where T is the derived hitbox type. However, the GenericCollisionsCallbacks class says that T has to be the type of the object to which the hitbox is attached. It looks like a bug to me.
    • the possiblyIntersects() method can be deprecated as well, since the intersection() method covers that use-case.

The biggest source of inefficiency with the current collision detection system is that whenever any two hitboxes need to be checked for intersection, they are projected into the "absolute" coordinates (i.e. the coordinate system of the canvas). This is expensive: not only some objects never move and therefore don't have to be projected each time, if there are N objects, we currently end up doing O(N^2) projections, whereas simply performing a projection once at the start of a tick and then computing the intersections on those would only be O(N).

• Cache projections of each hitbox onto the common collision plane.
  • The "collision plane" here is the common ancestor of all hitboxes, which is marked with the new HasCollisionDetection mixin (see item 1 above).
  • Projections are easy for hitboxes based on Shape class, which already implements the project() method.
  • We would need to keep track of which components have moved in the last tick, and re-calculate their projections.

Current ShapeComponent class (and descendants) contains both the "shape-component" logic, and also the logic for computing intersections between various shapes. This is too jumbled: we should

• Implement clean ShapeComponent class to be used in examples etc.
  • Only deals with drawing / moving a shape;
  • Supports multiple paints (so that you can have a rectangle with fill, border and shadow);
  • Has a simple flag to also add a hitbox, but otherwise handles hitboxes in the same way as other components do.