- 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/2D_GRAPHICS.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # 2D Graphics (`gfx2d`)
 
 ## Table of Contents
@@ -27,6 +29,11 @@ For the 2d rendering framework, Materials need to be rendered independently beca
 no size constraints for images. This disallows us from using a meta-shader like in
 the 3d rendering framework.
 
+I may have come up with a solution for the above problem. We can define software
+subsections for images that are of differing size, then fit them to the optimal
+texture array size. The textures will be centered in the storage, then have padding
+that fits one of the wrapping models supported by samplers
+
 ```c++
 struct Object
 {
@@ -61,4 +68,5 @@ struct Object
 
 - Translucent objects will be sorted. We can cheat by using a z-index instead of a z-coordinate.
   This will allow us to sort objects as they are created. We can still bulk render each z-index,
-  with meshes and objects being grouped by material.
+  with meshes and objects being grouped by material.
+

planning/3D_GRAPHICS.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # 3D Graphics (`gfx3d`)
 
 ## Table of Contents
@@ -67,8 +69,8 @@ Objects are identified with a manually provided type and ID. Object types includ
 A user should never have to specify these and should be automatically generated by the respective components.
 
 Textures for 3D rendering are stored in various buffers with sizes of powers of 2. Ratios of `1:1`
-and `2:1` are allowed. The `2:1` ratio is specifically for spherical and cylindrical projection. UVs
-may be transformed to use a `2:1` as if it were `1:2`.
+`2:1`, and `4:1` are allowed. The `2:1` ratio is specifically for spherical and cylindrical projection. UVs
+may be transformed to use a `2:1` as if it were `1:2`. Same applies for `4:1`
 Cubemaps and 3D textures may only be `1:1`.
 
 - 8-Bit R    Texture `4096, 2048, 1024, 512` (8)
@@ -170,12 +172,12 @@ Debug View: Visibility Buffer
         * S &rarr; used to represent the lighting model.
     * Diffuse &rarr; `RGBA8`
         * A &rarr; Ambient Occlusion
+  * Specular &rarr; `RGB8`
+      * R &rarr; Roughness
+      * G &rarr; Specularity (sometimes called the Metallicity)
+      * B &rarr; Index of Refraction (IOR)
     * Emission &rarr; `RGB8`
     * Normal &rarr; `RGB8`
-    * Specular &rarr; `RGB8`
-        * R &rarr; Roughness
-        * G &rarr; Specularity (sometimes called the Metallicness)
-        * B &rarr; Index of Refraction (IOR)
 
 Debug View: Depth, Stencil, Diffuse, Emission, Normal, Specularity
 
@@ -195,9 +197,9 @@ We can combine all of these into one framebuffer:
 - Depth - Stencil &rarr; `D24_S8`
 - Visibility Info &rarr; `RGB32I`
 - Diffuse &rarr; `RGBA8`
+- Specular &rarr; `RGB8`
 - Emission &rarr; `RGB8`
 - Normal &rarr; `RGB8`
-- Specular &rarr; `RGB8`
 - Lighting Buffer &rarr; `RGB16` w/ Mipmapping
 - One more slot left open for another
 

planning/3D_PHYSICS.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # 3D Physics (`physics3d`)
 
 ## Table of Contents

planning/ARTIFICIAL_INTELLIGENCE.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Artifical Intelligence (`ai`)
 
 ## Table of Contents

planning/CONTAINERS.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Containers Library (`containers`)
 
 ## Table of Contents

planning/CONTENTS.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Planning Documentation for fennec
 
 ## Table of Contents

planning/CPP_LANGUAGE.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # C++ Language Library (`lang`)
 
 ## Table of Contents

planning/ENGINE.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # fennec
 
 ## Table of Contents

planning/LANGUAGE_PROCESSING.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Language Processing Library (`langproc`)
 
 ## Table of Contents

planning/MEMORY.md

@@ -1,4 +1,6 @@
 
+<!-- I release these notes into the public domain -->
+
 # Memory Library (`memory`)
 
 ## Table of Contents

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.

planning/RENDERERS.md

@@ -0,0 +1,26 @@
+
+<!-- I release these notes into the public domain -->
+
+# Renderers (`renderers`)
+
+
+
+
+## Introduction
+
+&ensp; This library contains headers and classes related to creating renderers
+that wrap various graphics pipelines, e.g. OpenGL & Vulkan.
+
+
+## Implementation
+
+OpenGL will be implemented first for prototyping, then Vulkan will
+be implemented. These will be the first two renderers with official
+support. OpenGL will be implemented twice, one targeting modern features,
+and a fallback targeting OpenGL 4.3 / GLES 3.2.
+
+OpenGL will be wrapped in a manner that reflects the Vulkan API. This
+will help achieve higher performance with driver usage in OpenGL, and
+it will make building pipelines on top of OpenGL easier. This will also
+give the advantage of a cleaner porting process when writing the Vulkan
+pipeline.