roodletoof/cig
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update README.md

Browse Source
This commit is contained in:
Ivar Fatland
2025-11-04 21:31:59 +01:00
parent 97fef1ccc8
commit c848095946
1 changed files with 22 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+22 -23
View File
@@ -1,8 +1,8 @@
# ISSUES
No matter what I do it says that there are 2666 allocations or something. This
is concerning.
When a memory bug is detected in one of the treads it won't report a non-zero
exit code while running the tests.
# A collection of libraries inspired by zig
# A collection of libraries inspired by zig, and other stuff.
I like zig, but I really like writing C. I am starting with implementing
different allocator types. I don't know how the other parts of the library will
@@ -11,24 +11,23 @@ fit in, but they will certainly use the allocators.
I want a series of standard collection types with nice interfaces. ArrayLists,
LinkedLists, value-based HashMaps, reference-based HashMaps.
I also want to provide snippets for generating safe bit-flags and tagged
unions. This will be done with the X-macro pattern. As well as snippets I want
some sort of explanation of why the snippets are made the way they are, and
what value it provides to follow those patterns.
I also want to provide template header files that use the X-macro pattern so
that users can easily make tagged unions, option types, automatic bit-flags,
and maybe even an ECS inspierd struct filled with optional fields.
I probably want a ui library. It too wil rely on a graphical drawing interface.
It will be a little different though. It is inspired from my experience with
using raygui. instead of making some sort of layout engine, I will provide a
set of useful functions to manipulate rectangles. I think this produces
programs that are easier to reason about, while still reducing needless
duplication of code. The workflow relies heavily on function-static variables,
which are a c superpower in this scenario. You will essentially start with some
'fixed' rectangle (probably derived from the window size) and then perform
splitting operations on that rectangle. Even a dynamic split that creates a
draggable border, updating the local function-static variable (which is a
normalized float) to let you resize sections. Also, the interface will be like
immediate mode guis, with one exception from the way raygui works. The drawing
operations are deferred, and called in the reverse order. This way the first
gui function that captrues input can signal to the other function that input is
captured, and the drawing of the gui elements can reflect the priority of the
gui functions. Overlapping gui elements in raygui is the main painpoint imo.
I probably want a ui library. It will rely on a graphical drawing interface. It
will be a little different though. It is inspired from my experience with using
raygui. instead of making some sort of layout engine, I will provide a set of
useful functions to manipulate rectangles. I think this produces programs that
are easier to reason about, while still reducing needless duplication of code.
The workflow relies heavily on function-static variables, which are a c
superpower in this scenario. You will essentially start with some 'fixed'
rectangle (probably derived from the window size) and then perform splitting
operations on that rectangle. Even a dynamic split that creates a draggable
border, updating the local function-static variable (which is a normalized
float) to let you resize sections. Also, the interface will be like immediate
mode guis, with one exception from the way raygui works. The drawing operations
are deferred, and called in the reverse order. This way the first gui function
that captrues input can signal to the other function that input is captured,
and the drawing of the gui elements can reflect the priority of the gui
functions. Overlapping gui elements in raygui is the main painpoint imo.