Magmakit's current "demo" is a trivial platformer with tiles where all collision is implemented using AABB sweep-distance-normal tracing and a continuous contact solver. It's very slow. Runs at a decent framerate with only a dozen or so tiles, but very slow.
One of the unspoken design principles behind magmakit is that if a developer really needs to do something performance sensitive they should hack at the engine itself (magmakit) instead of doing it in gammakit code (which is slow) and hoping for the best.
I began constructing the skeleton for a Real, Proper collision detection system, which, naturally, being the masochist I am, I started at the broadphase instead of just looping through every single static and dynamic object and laughing at how much faster Rust is than Gammakit, because I figured I might as well do some "hard" programming to remind myself how much it sucks and make myself play more video games or something (which I haven't been doing enough of lately).
I decided to implement a
BVH system with AABBs (so, a dynamic AABB tree), because querying a quadtree or grid requires keeping a hashset/btreeset of all known potentially-hit objects, and I figure BVHs are better because they don't have that problem (this is the full extent of the thought I put into it; I really just wanted to do something I haven't done before, and I've made quadtrees and grids before). Again, people seem to call the type of BVH I'm implemented a "dynamic AABB tree".
The most straightforward explanation of dynamic AABB trees I could find is this blog post here:
https://www.randygaul.net/2013/08/06/dynamic-aabb-tree/ - it's a bit skimpy on some of the details, so I'm not sure I'm going to implement everything properly (no, I'm sure that I won't), but it's concise and seems straightforward enough.
After a couple hours of bashing on my keyboard, I have a working insert-only BVH system, or at least I think I do, there isn't really a formal specification of what BVHs really function like for me to check or anything like that. It turns out that BVH systems are very strongly heuristic-based, and changing things slightly can have a huge impact on the resulting arrangement of bounding volumes.
I have an album of how my BVH grows as I add more tiles to it here:
https://imgur.com/a/4cT4vTwIt seems that building a BVH gradually will inevitably result in strange obviously non-optimal collections of bounding volumes, as wikipedia puts it "BVHs also naturally support inserting and removing objects without full rebuild, but with resulting BVH having usually worse query performance compared to full rebuild". It seems that the right way to avoid this is to completely rebuild the entire hierarchy after a while if the tree is too inefficient, but I'm not really interested yet. Maybe once everything else is in place.