Reworking object math for big results

After applying the clang-format and beautifying the code yesterday, I couldn’t resist so I ended up reworking the way I store basic 3D object parameters and how they are used to calculate everything. The main point was that I originally used matrices everywhere to avoid having to deal with casting values or overthinking how to optimise for memory/usage. However, it was inefficient and made things harder to debug. This was an issue as I wanted to figure out how to solve the incorrect collision I was seeing when various projectiles where going through their targets instead of destroying them.

Therefore, I replaced these global 4X4 matrices used all over the place with translation vectors and rotation matrix (3X3). I was rewarded quite nicely for it because, after changing the type of values for the translation component of the base spatial object class, collision handling started working as expected!

Animated gif showing a full gameplay loop and accurate collision handling - You don't get hit when you shouldn't anymore!

Redesigning the way we store position solved collision problems

This game is now fair! No more getting hit when you shouldn't!

Time spent for this Time spent so far
6 h 101 h

Collision handling and first compromises

Collision handling turned out to be harder than expected… To get it working quickly, I relied on a bounding sphere for every models. The spheres are centered on the isobarycenter of the model and have for radius the distance of this point to the farthest vertex of the model. This is far from the perfect fit possible for a given model, but was faster to code. The way it works is that game objects register themselves during their update pass to the collision handler. Afterwards, the collision handler solves collision of the registered assets.

Time spent for this Time spent so far
8 h 41 h
[Read More]