TODO

[ ] Implementar o ghengin-core/planets-core
[ ] A hie.yaml file to fix HLS?
[ ] Drop type parameter from RenderQueue
[ ] We only need the parameter to the render queue because we don't yet attach render properties to meshes
[ ] Add render properties to meshes
[ ] It's definitely not obvious how to have the developer use and update materials and meshes while keeping them linear in the renderer.
[ ] Notes on how things are outside of Core can be good examples to demonstrate how Core works and is minimal
[ ] Write Note [Cameras are not part of Core]
[x] Plan: (1) Split into multiple packages to get HLS working again.
[ ]       (2) Make Ghengin unrestricted.
[ ]       (3) Get back to making ghengin-vulkan safe-only
[ ] Still need to make the batteries included engine (Ghengin) be unrestricted (need to use UrT to wrap Renderer)
[ ] Drop (Maybe Word) corresponding to Size in `BindingsMap`, it is no longer used.
[x] After "Remove Unsafes from Core", the planets application is able to run and generate meshes without crashing.
    However, after "Remove Unsafes from Vulkan", the application won't even start.
    Fix that. Fixed, it was a darn accidental recursive binding
[ ] I'm starting to think the Vulkan implementation should use Unsafe.toLinear
    *EVERYWHERE*, and simply provide a linear API on top of it.
    The individual functions are too painful to make linear.
[ ] Make revertable commit changing to multiple packages in a cabal.project file, so that we get LSP back (it + multiple components + backpack is broken)
[ ] Replace SizeOf with gl-block https://gitlab.com/dpwiz/gl-block
[ ] Use Geomancy.Gl.Block
[ ] Maybe we could make good use of streamly here somwhere
[ ] Make the Vulkan macos distribution and other distribution/exporter packages agnostic to ghengin
[-] That's right, we can use the normal apecs with a wrapper module that unsafe coerces the Renderer to UnsafeRenderer
[ ] Separate things like Mesh, Material and Pipeline references from Apecs. These should be kept in a renderer data structure really.
[ ] Picking up a previous idea, we should automatically make imgui editors for
    every game object that instances X, and enable said windows on keydown when
    compiled in Debug mode
[ ] Use LinearConstraints when those are available...!
[ ] Use HEAD fir when change is upstreamed
[ ] newtype Ur instead of data Ur, otherwise we're creating indirections everywhere... For now, correctness > performance
[ ] It would have been useful to create utilities along the way, instead of relying on hacky "faster" temporary solutions
    Now I have to that on a second pass. Starting with a logging module ....
    Now it being a calm enjoyable and more thoughtful refactor.
[ ] consumeM and dupM in reference-counting library, such that we can duplicate
    things in the monad, and eventually instance ConsumableM and DupableM on
    PropertyBinding.
    Wrong, for a couple of reasons (see unsafePerformIO documetntaiotn, side effect is too observable):
    Interestingly, we could have a dupable instance on aliased
    values, just not a consumable one, since we can unsafePerformIO the atomic
    counter increment. I suppose we just inline its definition for now
[x] Re-export things like apecs from Ghengin so that it needn't be depended upon
[ ] Include API design (and namespace design) in architecture design/refactor document
[ ] World as a modular thing, perhaps like an HList to which we can add as many components as we want, while still defining type predicates
[ ] Unrestricted wrappers on Ghengin for all functions users might need from the Renderer
[ ] Diagrams of the architecture, how do subsystems connect, what's concurrent?
[ ] ARCHITECTURE.md;
[ ] Revert linear Ghengin interface. Keep linear Core.
[ ] Compile with "incorrect semantics linear-apecs" linear Ghengin, then do the task above
[ ] I Don't think I'm going to keep a linear interface to Ghengin, but rather
    use UrT to wrap the linear Renderer and Core Ghengin. This would allow us
    to use normal Apecs, without the linear performance regressions and
    incorrect semantics (I could probably fix the semantics with dupable, but
    then incur in even more performance regressions).
[ ] Hot reloading textures
[x] It's currently a very unsafe frankenstein, but really make it compile again before improving it, as a hobby, I can take as many time as I need refactoring everything just for the sake of a more beautiful program
[ ] First worry about correctness, then about the performance regressions of using linear types
[ ] More on WebGPU https://cohost.org/mcc/post/1406157-i-want-to-talk-about-webgpu
[x] Performance of linear-apecs is much worse than normal apecs. Probably we need to revert to using it...?
[ ] Write a backend for the new WebGPU! Make games for the web?
[ ] Better abstract graphics API? https://wickedengine.net/2021/05/06/graphics-api-abstraction/
[ ] Again, deferred rendering https://lettier.github.io/3d-game-shaders-for-beginners/deferred-rendering.html
[ ] Use linear constraints with ~~9.8~~ 9.10
[ ] Ghengin should not mention vulkan anywhere outside of the cabal file that
    instances Core.Renderer with Vulkan.Renderer. For now, though, we use Vulkan
    only while we don't figure out the parts of the API that still depend on Vulkan
[ ] Exchange reference counted instances to Generic based instances to avoid bugs
[-] Perhaps linear-apecs components should be dupable rather than unrestricted,
    so something like a reference counted pipeline can be stored in apecs, and be
    shared as many times as needed without it ever being unrestricted (of course,
    in requiring Dupable people can still store Ur elements there, so it's less
    restrictive than requiring Ur).
[ ] Get rid of StateVar ?
[ ] The World should really be an heterogenous list such that we can add and remove compontents at will, meaning the list of components we're using is more modular (we can add the transform animation components storage only if we're using animation). Though we can still have some built in ones.
[x] We could have an unrestricted Ghengin monad simply by wrapping the linear
    bits with UrT!... Perhaps as an alternative instanciation of Ghengin? So
    we'd have linear-ghengin and just ghengin, but the core of both,
    ghengin-core, is always linear and resources there are carefully threaded
    through, so implementation wise resources are not forgotten. In games, we
    can relax what we enforce in the types regarding resources, or keep them still
[ ] Write some nice comments about how to use linear types with Dupable and Consumable and UrT that makes things Monads, those are really useful. Write a blog post about it even.
[ ] Make better use of Consumable and Dupable... (linear types cleanup) (e.g. consumeUnits is just a specialisation of consume from Consumable -- change it.)
[ ] ghengin should not import Ghengin.Vulkan either. It should simply ensure
    (for now) that ghengin-core is instanced with ghengin-vulkan, but later on we
    might even delegate that responsibility to the user
[ ] Much more parallelism... both host and device (GPU)
[x] Clean up ghengin-core and ghengin-vulkan (better utils, custom prelude and
    exports in cabal (-XNoImplicitPrelude), linear by default (-XLinearTypes, -XQualifiedDo), block args too)
[ ] Longterm: WebGPU backend + WASM GHC compilation
[x] Ghengin.Prelude
[x] Gigantic refactor using linear types and backpack sigs for the renderer
[x] By default, QualifiedDo and NoImplicitPrelude in ghengin-core and default to Prelude.Linear (and perhaps in ghengin-vulkan and others too)
[ ] Fix stuttering most likely due to update not being run per frame in flight
[ ] Move ghengin-package-macos to more general packaging solution
[x] Fix type errors and implement all of the logic of the camera in userland to experiment its expected feasibility
[x] Camera should be updated for every render pipeline. How to do stuff to
        either all render pipelines/all materials? Perhaps direct hooks to those places
        would be the sanest way: An answer is to use explicit references as we did.
[ ] Level editor called with flag (could perhaps toggle game inside the level editor) to move things around and change properties displayed through imgui windows
[ ] Fix segfault caused by freeing descriptor set in render pipeline
[x] Edit for all render properties instead of just material (migrate medit)
[ ] Fix Frames in Flight (completely-redo-it)
[ ] Un-built-in Transform and the push constant that pushes it
[x] Consider moving Ghengin.Core to its own package
[x] Use `Syntatic` and compare with `InternalType` and equality instead of SizeOf
[x] Move hardcoded bindings out of render pipeline and instance it with properties instead
[ ] FIR doesn't check compatibility between vertex data and vertex shader inputs
[ ] Instance `Syntatic` to support the engine data types at the shader level
[ ] Perhaps use more efficient list-like type by default for creating meshes
[ ] Dear imgui specific render pipeline
[x] Custom descriptor set #0 through Render Pipeline constructors + edit function similar to Materials
[ ] Untangle World {-# SOURCE #-} imports by creating another module for it
[ ] Hex map tutorial series https://catlikecoding.com/unity/tutorials/hex-map/
[x] Compatible mesh constraint with working planets example
[x] Get rid of VertexArray altogether (use Storable Vector directly)?
[x] Successful packaging for macos that bundles vulkan dylibs and assets
[ ] Fix gradient and move it to another package
[x] Conditionally enable extensions required by apple silicon only on apple silicon
[-] Patch cabal-osx with more up-to-date directory structure (e.g. PkgInfo should be in Contents)
[x] Basic packaging using cabal-osx
[x] Basic Packaging/Distributing (requires item below and requires things like bundling vulkan)
[-] Resource wrapper that gets resource through special hoops depending on the system (e.g. using CoreFoundation in MacOS and iOS)
[x] Flexible Mesh types checked against pipeline
[x] Sharing RenderPackets makes mesh because multiple ones will be freed multiple times (since we don't de-duplicate meshes, but rather render all meshes in render entities agregatted by material) (reference count drop below 0)
[-] If using MonadRender, -fspecialize-agressively might be useful, but it will probably already specialize...
[ ] Currently, if a texture or sampler is not used in a material then they aren't freed (textures and sampler are freed and reference counted through materials)
[x] Reference count Textures and Samplers
[ ] Instances for safe coercion between ImGui types and Geomancy (using unsafeCoerce :P)
[x] Linear types for resource management
[-] MonadRenderer to be able to call mesh creation and such from SystemT
[ ] Toon Shader
[ ] Automatically derive UISettings? (This goes in line with the idea of making an editor-mode which allows things to be edited by default through imgui panels)
[ ] Swap chain recreation...
[x] Would it be bad having two layers of ECS (rendering + user)? <-- This wouldn't work because the user-world must also know of render packets and such, since it wants to add and manipulate them
[x] Better solution for memory management (linear types, gc, bla bla). Right now we require shared resources (like textures) to be manually freed, while material local resources are freed by the engine.
[x] Build macos app bundles
[0] If I ever have a big enough game, processing all assets at init will be slow, and we should otherwise store the processed data in a resource manager database
[ ] Unity tutorial project

[ ] Fix GUI Gradient by removing (static) global markers
[ ] Move GUI Gradient to separate package
[c] The UISettings doesn't need the type family... wouldn't it be better to add the entity as a parameter to the PlanetSettings?
[.] Gradient GUI editor. (TODO: left align it...)

Next steps:
[x] Update UI in the imgui way instead of that terrible boolean
[x] Function to update material properties which fixes the existential issues
[x] Free all textures at the end, and material resources when the material is "removed".
[x] More flexibility picking the sampler. (Next step: would it be good to have the sampler separate from the texture and simply appear in the texture material binding?)

[x] A good hashble instance for Textures, or assign material ids with an atomic counter of sorts which would make things much easier than Hashable...
    Solution#1 Use TypeRep as a pipeline's unique identifier, and create Uniques to uniquely identify materials
[.] Compatibility between binding types (can't match dynamic binding with texture2d)
[ ] Fix second planet. Its color is probably too bright because of its minmax
    being computed from the first one bc of the mesh recreation thing. once again, we need to fix the UI.
[x] Free descriptor sets and descriptor set resources
[-] Function to update static binding value that simply writes the buffer. The static binding should have a device local buffer which is not that easily written to
[x] Use an atomic counter for the material ids? https://github.com/sergv/atomic-counter
    Solution#1
[x] Somehow (through Typeable and pattern matching on runtime on the kind of
    packet) allow to update existentials. This function should also free the mesh/or material updated before creating the new one.
[ ] Material type list doesn't have to be traversed in reverse... the first item in the list could be binding #0 without any issue
[ ] Custom lights in descriptor set #0
[x] Should the descriptor set #0 be fixed for always needed engine data? (hardcoded) always camera position, lights positions, lights types, ...
    No!! Ghengin Core removes those hardcoded bits with great success
[x] How to specify arbitrary descriptor set #0 (pipeline global data) and descriptor set #2 data (per model data).
    We've seen how, see Ghengin.Core.Render.Properties
[x] Free the discarded descriptor sets in the materials (read below) (or at least the mapped buffers)
[x] Free the materials during execution: careful they might be shared.
[x] Which UI changed? Currently we don't know and are simply updating all meshes the same
[ ] Array of textures for textures shared across mats?
[x] Q: Should I allocate a descriptor set per material? Is that common?
    A: Yes. It'll occupy some memory but it would require many many materials
    to ever reach the limit. It also makes things much simpler and fixes the
    mats not changing bug and the static binding design
[x] A 'material' function to create/update? materials which allocates the descriptor set (read below)
[x] I think I can't write the same buffer in between draw calls as it seems
both will end up with the same color. It seems as if each material needs its
own descriptor set allocated and the dynamic bindings simply write the buffers
every frame, and the static bindings don't.
[x] A function to update materials (read the one below).
[x] Nailed it: A solution to update the existential materials: I think we'll have a typeable instance (like a runtime type tag) that allows us to pattern match on the type of the material to understand what kind of material it is. Then we know the type of the material and we can safely update the property value. 
[x] Compatible must ensure all required input parameters in the shader are defined in the material
[.] Render packet data for global descriptors properties and for model descriptors properties rather than just the material properties
    (Missing mesh properties)
[x] Compatible material constraint with working planets example
[x] Materials must have a compile time size to compare with the size of the descriptors defined in the shader.
[x] Static bindings which simply choose the descriptor (set?) rather than write to it
[ ] Better scene graph implementation
[+] Use parent component, a cached world matrix?, and a wrapper api that threads entities ids.
[ ] Cache world matrix through lazy field in Transform instead of explicit calculation ?
[x] Textures to use with MinMax terrain height
[x] Complete the phong model (and try some Specular lighting)
[-] Scene graph should (polymorphically?) cull the space, and
in the visible space order meshes by pipeline and material
type. Good algorithm that sorts geometry in the best possible way for the engine
[x] Free render pipelines
[y] Should each static material have its own descriptor set which simply gets bound instead of writing always over the one created with the pipeline?
[x] Validate at compile time the meshes and materials registered for a render pipeline. (Missing: mesh validation)
[-] Scene graph (BSP, quad/octtree)
[?] Disallow non-uniform scaling so that calculating the normal in world space is simpler
[x] Who's pulling in lens? Maybe I can benefit from them if I already have to have them. (Answer: fir)
[.] Bundle descriptor sets, render passes, and pipelines into a single abstraction. (Missing: render passes)
[x] Index buffer
[-] Since for now we decide a game can ever only use one window, we could have
    the Ghengin monad propagate the window thorought the program