* VEFontCache needs to get fixed up (possibly bring back ELFHash)
* Problably going to do conversion early to odin's array and map usage
* Need get the quad tree setup for the ui so that I can do fast and efficient traversal for the layer based rendering.
* Added todos for VEFontCache
* Going be remaking the direct box traversal rendering again, I'll keep both layer based and it as a option to switch between
* Need to implement a quad tree for the ui boxes to help with collision test traversal
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
HMapChained causes memory corruption in VEFontCache (not sure why yet), so I switched temporarily over to HMapZPL.
Fixed bug with parser_get_glyph_shape from me tracking vertices as u16s instead of i16s.
Currently a bug with the frametime example:
text_test_str := str_fmt("frametime: %0.2f", frametime_avg_ms)
It doesn't handle per-frame updates properly compared to C++ source
I'm enforcing aprintf it as the default formatter.
I changed up the context allocator assignment to reflect how I've been intending to allocation in startup & platform events vs tick.
Tick uses the frame slab's by default with transient on temp. Startup & platform events use the transient by default & for temp, with any use of the persistent allocator being explicit.
Switched frametime_delta32 to frametime_avg_ms.
I'll problably rename it and keept delta32 for actual delta. Reading over the sokol_app code I noticed it uses the avg frametime and definitely want to do that for spike alleviation...
I'm sticking with not supporting the top-left alignment for default and instead going with bottom left.
This allows for 0,0 alignment to the "bottom left pivot" for a box and 1,1 to the "top-right pivot" of a box.
These naturally coincide with where the actual min-max points that define the box are for the coodrindate convention I decided to go with. I'll write docs to migitate confusion.
Now I just need to fix the layout presets I have for the currently existing constructions...
Got an initial variant of the drop down widget, not completely set on it..
I put some more time to figuring out how I'm going to be ideomatically constructing the widgets. screen.odin I think its getting pretty close to what it will be like.
I'm ready to start lifting the input box. I'll be adding the constraints when I lift it.
Added the option to toggle the debug text in screenspace
Added the fixes from the ui_layout_children_horizontally for margins to ui_layout_children_vertically
Known issue:
There is a bug with test_whitespace that forced me todo a null check on a box. Not sure why.
It needs to be redone anyway.. (compose it with the h/vboxes instead)
There is some sublime files added in, started to use it.
Going to get sokol_gp soonish
Need to look into figuring out text rendering...
I'm preemtively getting this stuff now but I problably won't be swapping raylib impl anytime soon.
Renamed KeyboardKey to KeyCode, redid the encoding layout (preemtively getting ready for SDL later as well)
I got the input box working but it has no constraints and needs to be lifted. The scroll box construction does as well.
Moved core ui to its own folder.
Worked on theming (proper light and dark theme)
Began to work on the scroll box widget and input box constructions
I added back a script for flattening the codebase: gen_flattened_codebase.ps1
I now generate the layout the compiler wants, eventually I'll just have a custom policy so that the compiler can accept the non-idiomatic layout
See scripts/build.ps1 & gen_staged_compiler_codebase.ps1 for how this is handled.
Still need to add support for centered resize of boxes with the handles. (Will need a different alignment configuration)
Theme manipulation is getting cleaned up iteratively code is slowly looking less nosiy
Going with dark mode at first,
I'll also be making a lightmode, but I want to have a post-processing shader for tonemapping the app screen's tone by the user before doing so.
