Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Phantom Brave]

The dream never dies. Gammakit and magmakit live on.

https://streamable.com/8bhr2

TODO:

- shader control functions
- surface drawing
- sampling from multiple textures in a single shader
- built in collision system (circles, n-gons. functions return a list of all possible results. transparent broadphase)
- pack/unpack pseudo-json from strings

- simple sample-and-emitter audio system, no busses, mixer channels are tags
- faucnet style networking api

- load or write strings or byte arrays to files
-- networking style buffer access with byte arrays?
- text with internal formatting
- interact with native DLLs...?
- fun stuff like font size control, drawing with transforms, colors, etc etc etc... it is all endless


https://github.com/wareya/magmakit
https://github.com/wareya/gammakit

[Phantom Brave]

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/4cT4vTw

It 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.

[Phantom Brave]

I have a working BVH (addition, deletion, and moving), polygon-polygon tracing, and circle-circle tracing. Now I need polygon-circle tracing, discrete collision tests for all three collision body types (i.e. place_meeting), and to tie everything together.