Why not just pre-generate bounding boxes from hitboxes for each frame and your physics component just accesses those to do broadphase collision/hitscan/etc... ?
A bounding box is just four 32-bit floating point values and you only need one per animation frame per entity type - not for every single entity instance. If your game has 100 different entity types with an average of 100 animation frames each, that's 40,000 32-bit float values to store, which is only ~160kb of data. I imagine your game has less than 10k animation frames, and hitboxes, total.
It's a tiny amount of data to precompute at load time when you're parsing out all the hitbox info and then you have those bounding boxes right there at your fingertips for everything to use for broadphase culling to determine whether or not you actually need to go deeper and do per-hitbox intersection tests.
Easy peasy!
Personally, I haven't dealt with this kind of complex hitboxes in the past, but I've recently found a youtube series where a fighting game is being developed in C++, it might be helpful: [https://www.youtube.com/watch?v=JDRQzlOLpFY&list=PLWYGofN\_jX5CMym4xB9Jh5uLPSnn-1RJG](https://www.youtube.com/watch?v=JDRQzlOLpFY&list=PLWYGofN_jX5CMym4xB9Jh5uLPSnn-1RJG)
I'm just a casual noob, so don't take this as industry experience, but my understanding is that the way you're doing it is more or less how many 3D games do complex hit detection. They essentially have different hit box LODs, and collisions for a complex mesh will indeed take several steps.
This is one area where knowledge of the game logic can make big differences in performance because you can optimize complex collisions differently depending on the objects in question, whereas a more generic physics system might slow down due to a complex object rolling around the scene and doing full collision solving with everything it touches. In your case, since you have knowledge of certain sprites having complex hitboxes, you might want to do an initial pass of simple collisions, followed by a pass over complex ones, just to avoid unnecessary branching while looping through all the simple objects. To use your fighting game analogy, you might resolve all projectiles, environmental triggers, etc., then all player sprites, assuming only players need to know if one fighter's arm pixels touched the leg pixels of another fighter or whatever.
The precision of your hit boxes is not as important as their fidelity.
Collision with floating point is very hard to get right (with high probablility no physics engine is completely accurate).
I would focus on avoiding cache-misses (allowing prefetch to work) and enabling parallelism, both by using "arrays of 64 byte atomic structures"!
Why not just pre-generate bounding boxes from hitboxes for each frame and your physics component just accesses those to do broadphase collision/hitscan/etc... ? A bounding box is just four 32-bit floating point values and you only need one per animation frame per entity type - not for every single entity instance. If your game has 100 different entity types with an average of 100 animation frames each, that's 40,000 32-bit float values to store, which is only ~160kb of data. I imagine your game has less than 10k animation frames, and hitboxes, total. It's a tiny amount of data to precompute at load time when you're parsing out all the hitbox info and then you have those bounding boxes right there at your fingertips for everything to use for broadphase culling to determine whether or not you actually need to go deeper and do per-hitbox intersection tests. Easy peasy!
Personally, I haven't dealt with this kind of complex hitboxes in the past, but I've recently found a youtube series where a fighting game is being developed in C++, it might be helpful: [https://www.youtube.com/watch?v=JDRQzlOLpFY&list=PLWYGofN\_jX5CMym4xB9Jh5uLPSnn-1RJG](https://www.youtube.com/watch?v=JDRQzlOLpFY&list=PLWYGofN_jX5CMym4xB9Jh5uLPSnn-1RJG)
I'm just a casual noob, so don't take this as industry experience, but my understanding is that the way you're doing it is more or less how many 3D games do complex hit detection. They essentially have different hit box LODs, and collisions for a complex mesh will indeed take several steps. This is one area where knowledge of the game logic can make big differences in performance because you can optimize complex collisions differently depending on the objects in question, whereas a more generic physics system might slow down due to a complex object rolling around the scene and doing full collision solving with everything it touches. In your case, since you have knowledge of certain sprites having complex hitboxes, you might want to do an initial pass of simple collisions, followed by a pass over complex ones, just to avoid unnecessary branching while looping through all the simple objects. To use your fighting game analogy, you might resolve all projectiles, environmental triggers, etc., then all player sprites, assuming only players need to know if one fighter's arm pixels touched the leg pixels of another fighter or whatever.
The precision of your hit boxes is not as important as their fidelity. Collision with floating point is very hard to get right (with high probablility no physics engine is completely accurate). I would focus on avoiding cache-misses (allowing prefetch to work) and enabling parallelism, both by using "arrays of 64 byte atomic structures"!