krink is a lightweight, ultra portable framework built on top of Kinc, written in C using C99. It adds:
- a 2D rendering API very similar to what Kha provides but with additional capability to render 2D SDF shapes
- ECS integration
- Nuklear built in for UI
- Integrated Memory Allocator
- ...
krink is being developed with a focus to target mobile devices primarily but is none the less extremely portable, successfully running on a wide range of devices, operating systems, CPU architectures and graphics APIs:
OpenGL | Vulkan | Metal | Direct3D | Other | |
---|---|---|---|---|---|
Android | X | X | X | ||
iOS | X | X | X | ||
Linux on ARM | (?) | X | X | X | |
Linux on x64 | X | X | X | ||
macOS | X | X | X | ||
Windows | X | |
|||
HTML5 | X | X | X | X | |
From the Kinc Readme:
Console support is implemented via separate plugins because the code can not be provided publicly - contact Robert for details if you are interested in it
A Canvas type rendering API to draw textures, geometric shapes, text and SDF shapes (because we all know the best rectangles have rounded corners! 🧐 )
krink ships with the powerful and awesome ECS library flecs, complete with built in flecs modules to make use of the 2D rendering capabilities krink provides.
The use of flecs is optional and has to be manually initialized.
krink contains a slightly modified version of the
Nuklear immediate mode UI library that can be
optionally used for user interfaces, rendered directly using the graphics2
API from krink.
The use of Nuklear is optional and has to be manually initialized.
krink provides a TLSF implementation to manage memory which
is enabled by default.
This can be disabled by defining the macro KR_NO_TLSF
to use the provided functions from
<stdlib.h>
.
In addition it comes with a minimal allocation tracking API that is only enabled with DEBUG builds,
which comes with additional overhead. This can be disabled by defining the macro
KR_NO_ALLOCATION_TRACKER
at compile time.
A large part of the API of krink is documentented using Doxygen style comments and the
documentation can be automatically generated using the provided Doxyfile
using
Doxygen and running doxygen Doxyfile
in the base directory of krink.
Eventually I hope to find the time to enable propper automatic API docs generation to either be self hosted somewhere or using a service like DocsForge
As of now there are no separate samples to demonstrate how to use krink, but there are small test programs located in the Tests folder that should get you started with krink and as a wise friend of mine often says:
"Have a look at the code, it's the most accurate form of API documentation" /s
While I'd like as much feedback as I can get to improve krink, I feel it is important to state that this is very much a work in progress and still in a very early stage where the API is still being extended and potentially breaking changes to it can (and likely will) happen.
In the hope of not having deterred everyone, feel free to:
- open an Issue
- make a Pull Request
- start a Discussion
- gain access to the Kode Discord Server Disclaimer: I'm just a member there and don't currently see any need to open a separate Discord server for krink
- follow/contact/DM me on Twitter @tizilogic