I do not come in peace; I am here on a mission. I wish to vanquish the angles and trig which run amok
To my knowledge, this seems to stem from the thought:
The user provides and requests angles, therefore my formulas should input and output angles
At the very least, this is untrue in that the user provides degrees and we compute with radians
But more pervasively, I argue that the formulas are first and foremost Geometric and not Trigonometric
| // Port of some collision functions to Odin by Jakub Tomšů. | |
| // | |
| // from Real-Time Collision Detection by Christer Ericson, published by Morgan Kaufmann Publishers, © 2005 Elsevier Inc | |
| // | |
| // This should serve as an reference implementation for common collision queries for games. | |
| // The goal is good numerical robustness, handling edge cases and optimized math equations. | |
| // The code isn't necessarily very optimized. | |
| // | |
| // There are a few cases you don't want to use the procedures below directly, but instead manually inline the math and adapt it to your needs. | |
| // In my experience this method is clearer when writing complex level queries where I need to handle edge cases differently etc. |
| Complete stuff: | |
| https://xmonader.github.io/letsbuildacompiler-pretty/ | |
| Lexers + DFAs: | |
| https://gist.github.com/pervognsen/218ea17743e1442e59bb60d29b1aa725 | |
| Parsing: | |
| https://eli.thegreenplace.net/2012/08/02/parsing-expressions-by-precedence-climbing | |
| Backend: |
The Gilbert–Johnson–Keerthi (GJK) distance algorithm is a method of determining the minimum distance between two convex sets. The algorithm's stability, speed which operates in near-constant time, and small storage footprint make it popular for realtime collision detection.
Unlike many other distance algorithms, it has no requirments on geometry data to be stored in any specific format, but instead relies solely on a support function to iteratively generate closer simplices to the correct answer using the Minkowski sum (CSO) of two convex shapes.
