NOTES

 - Write a simple shader preprocessor
   - #include
   - #define
     - probably not even function-style defines, but, maybe? eh.
   - #ifdef / #ifndef
 - At some point, look into using the new SPIR-V stuff (glShaderBinary and friends)
 - Build GLFW and GLEW ourselves?
 - Switch to Uniform Buffer Objects instead of regular OpenGL uniforms
   - For the transformation matrices and.. anything else? ...
 - Load chunks in order of distance from player when we're 
   loading a player in a world for the first time (since they last left the world)
 - care about memory leaks.
 - Fix the raycaster to not use _three_ different ray intersection tests
   - I think the math is correct; assuming this is the case, I must be doing something
     else wrong; bad data somehow? float vs double? (doubt it but maybe?) really idk :/
 - Add flood-fill (Minecraft-style) lighting(?)
 - Audio
   - 3D support, of course
     - OpenAL provides this right? yeah.
     - Reverb (i.e. in caves / large rooms, etc.)
     - Muffling (i.e. underwater, sound passing through materials, etc.)
   - Sound Effects
     - Block break, place, interract, and function (i.e. crackling of furnace burning coal)
     - Player footsteps; depends on material being stepped on.
   - Music i.e. background music on some sort of non-stupid loop (looping through multiple
     songs, that is), mixing in periods of silence. (Make this settings-tweakable!)
     - Of course this implies having music available to be used in this game, which I don't :P
       But, ykno.
 - Moon, Sky, Stars, Clouds, Rain, Thunderstorms, Snow
   - Moon phase too! Because why wouldn't we have that lmao.
   - Star flicker! Because pretties!
   - Differentiable (total [purposeful] abusive misuse of that term lmao) cloud density,
     and perhaps other variables too? i.e. weather dependent cloud coverage, type(?), etc.
 - List component for Load_World gui, etc.
   - Smooth scrolling, correct clipping, able to handle auto-scaling for its elements.
 - Instead of just using ByteBuf and straight serializing everything,
   use a structured format similar to NBT so that we can make save
   data that works even after the game code has changed/updated.
 - Create a "more proper" renderer
   - Not quite sure what I meant when I wrote this; I suspect I was thinking something
     along the lines of trying to unify all of the rendering code. Right now we have
     many different renderers, essentially; we have the Batch_Renderer, the World renderer,
     and a bunch of smaller renderers: sky, block highlight / AABB, Compass3D, etc.
     We would generally prefer to be able to, in a way that is just as performant or faster,
     draw all of these different things by going through the same pipeline. This implies
     we'll need to write it as a much more general renderer than the things I've got currently,
     including even the Batch_Renderer. We need the ability to support static, partial-dynamic,
     and fully-dynamic (streaming) drawing. For example: chunk rendering is partial-dynamic; we
     only need to update the actual mesh data when a chunk changes or we need to re-sort it.
     Whereas things like say, drawing AABBs for block highlights or debugging need to be fully
     dynamic. As for things like Compass3D, it seems that, trivially, this would be purely static.
     Actually, hmm; maybe the AABB rendering thing could be static too, in the sense that, I think,
     we could get away with just using a transformation to draw the AABB at the right position
     and in (of? idk grammar) the right size; translate & scale. But, I digress.
   - May we also want to look into more complex rendering techniques? Like, idk, the first thing that
     comes to mind is "scene graph". Not sure; that term feels somewhat vague/general tbh. I know uh..
     BVHs are a thing; although I don't think they're really applicable here? Idk man. Research needed.  
 - Physics
   - Swimming physics
     - Extra jump height when in water and at edge of block that the player should be able to jump up onto,
       to get out of the water.
     - Also, uh, probably have to ykno, implement water before this :P But, ykno.
   - Gravity for entities (at least for entities that aren't immune to gravity :P)
   - Gravity for falling blocks (sand, gravel, etc.)
     - In minecraft this is implemented by having a block start falling by removing said block from
       the world and spawning in a "FallingBlockEntity", for example. And then once that entity
       hits the ground it kills the entitiy and sets the block at that position. Simple enough in theory.
       However I suspect the mechanics behind actually initiating these falling entities is slightly less
       trivial. I say that, thinking about uh.. in Minecraft you often see, for example, sand blocks that
       were generated by the worldgen and not touched by the player, which are "floating in midair" -- they
       don't start falling until the player causes a block update around them. And then the falling start
       causes a block update at that block (presumably by way of the block removal, maybe) which then can
       trigger a cascade of falling such blocks.
 - Configurable keybinds
   - Sub-GUI of Settings; store in settings config file (currently nonexistant).
 - debug visualizations, etc.:
   - chunk heatmap view
     - i.e. each loaded chunk would be a cell in a grid drawn as a heatmap
       the `heat` would be, presumably, the amount of time spent either
       ticking or rendering said chunk.
       we could also apply this to memory usage.
     - keep in mind: ImPlot also has histograms..
 - add a minimap (and a fullscreen map :P)