- Changed directory structure significantly, moving gfx api implementations to fennec/renderers

- Began new overarching window interface
 - Began outlining renderer interfaces
 - Began a binary tree implementation in bintree.h, this will act as a generalized binary tree, then red-black tree will be implemented on top of it for sequences (ordered sets)

planning/PLATFORM_SUPPORT.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Platform Support Library (`platform`)
 
 ## Table of Contents
@@ -67,3 +69,56 @@ then support for other platforms will be resumed.
 with the principles of this engine. fennec will avoid using proprietary libraries except
 when strictly necessary, such as support for Windows and MacOS. fennec will interact
 with any drivers required for the listed operating systems above, even if proprietary.
+
+## Notes
+
+We want this system to be fairly modular, renderers and their respective
+gfxcontext implementation should be a drop-in, as well as window implementation.
+This is a fairly complex problem to solve, especially since most display protocols
+have their own specific implementation for supporting different contexts.
+
+To illustrate this problem, let's say we have SDL and OpenGL implemented.
+
+If we were to add Vulkan, there are Vulkan specific functions
+for creating a window compatible with SDL, i.e. SDL_Vulkan_CreateSurface.
+Who should know how to implement this function? How do we define the API
+so that we do not have to modify existing classes to add Vulkan support?
+
+The easiest solution to this problem is template functions. We can have a
+template that takes a Renderer type as a template parameter, then initialize
+the window for that. Now, if someone wants to create a Vulkan renderer, all they
+have to do is write an overload for the template function. This can be neatly
+wrapped up in a single C++ file. Only the gfxcontext implementation has to know
+of this function's existence since it will be the one calling the function.
+
+The main drawback with this implementation is an outside observer calling the
+template function directly. Only the one C++ file knows of its existence. Template
+functions are inlined after all. There are two options to solve this, the ``[[noinline]]``
+attribute, or we simply scope protect the function and create it purely from a
+"driver" standpoint. We can register drivers with the platform, then retrieve a
+list of drivers with a specific type, e.g. glcontext, then the type aware implementation
+is isolated to the C++ file associated with glcontext, and glcontext registers
+itself with the platform. We can give drivers a priority so that Vulkan, a more
+modern and "more powerful" renderer is chosen first, if available, and falls back
+to OpenGL.
+
+Now we run into the issue of, what if we want to implement Vulkan and Wayland separately?
+These implementations will be part of the core engine, but let's take a more contrived
+example; X-Box and Playstation. X-Box and Playstation have their own protocols for
+display rendering, but both use DirectX. Say someone implements a DirectX api for Desktop
+computers, then someone else implements a windowing system for X-Box or Playstation. 
+If another user wants to use DirectX with X-Box/Playstation, they will have to write
+their own overloads for that implementation.
+
+The only viable solution for this problem is to rely on the Open Source community.
+Pray that someone finds both engine extensions and writes the overloads for you.
+This might sound very familiar to modders, and this is my intention with this engine.
+Pieces should be modular, and should be easily connected when two non-dependent systems
+have underlying interdependencies.
+
+There is one more option that I have come up with; mapping type ids. The implementation
+of typed.h generates type ids *at runtime* which allows us to map a pair of ids for this
+purpose. We can use a pair of window and gfxcontext uuids to determine the loading functions.
+All we would need to do is register a function that takes a window as an arguments and 
+constructs the gfxcontext. We can combine this with the above to allow scoped access to 
+the classes if that is needed.