Anything considered static can be aggregated into a single VArena. We don't have to worry about ever releasing its memory or it growing "too large". All memory here must be fixed sized.
Conservative persistent memory can grow on demand but we would perfer if it could be trimmed or released when no longer dealing with heavy scenarios. Persistent memory should use a slab allocator that is backed by a virtual address space pool allocator instead of pools allocating from a single varena. Chained Arenas can source thier chunks of vmem from the slab which can be utilized for scratch memory. Fonts should be loaded from VSlab. The string cache should use a dedicated varena with 16-byte alignment. All conservative memory should be trimmable by a wipe command which should free all unused blocks. Each block should be a single OS aware reserve of vmem.
The Frame can possilby stay as a single varena with scratch allocation utilized on demand. Although it may be more viable for chained varenas to be derived from the main varena via a slab or pool interface. Frame memory should be trimmable on command which should release its committed vmem to its initial value. A dedicated transient varena should not exist. It should be removed when possible. File mappings for now can use a dedicated varena made on demand with a capped reserve size of 4 meg. Any file exceeding this needs the host to support virtual memory mapped I/O for files. The codebase db will use sqlite for the file I/O abstraction.
Host might only need to track the first persistent block of vmem, and the rest can be handled by the client (including wrapping that vmem up in a varena). Hot-reload only needs persistent vmem's ref restored on the client module's side. All other references can be resolved from there.
Still need to figure out input event consumption, I don't want to do it with the event ring.
I would like to setup input binding layers and then have the push/pop input contextes with a set of bindings.
If the bindings are detected it should "consume" that binding from further use for the buffered time period.
This will be really important with how heavily model this app will be.I
Renamed HashTable to HMapZPL, with procs having the zpl_ namespace prefix.
(I want to eventually get away from using it)
Started to use the grime pattern for library aliasing better.
I originally wanted to reference Ryan's UI series along with the RAD Debugger codebase, but that ended up being too convoluted of a route. Instead, I moved on to just doing a deep dive on imgui content I could find to learn from and associated libraries available. I collected my notes so far in this repo [IMGUI_Notes](https://github.com/Ed94/IMGUI_Notes).
For now I have the base scaffolding datatype wise for the prototype ui.
There is now a 2D camera in the workspace!
We have a basic 'Frame' definition. It doesn't have any interaction yet...
I started to define spacial math, mostly for doing conversion and getting a grounding on pixel/points/cm reference. The world space is in cm.
Doesn't work across app runs, unlike handmade the crux here is raylib. Even if we did raylibs features ourselves there would still be an issue of restoring the gpu memory state. So in order to have replays work across app runs is proper state serialization.
I'll leave that for later and focus on the next core features.
ed