krink

About

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:

where krink runs

| | 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 | <br> <br> | | | HTML5 | X | X | X | X | <br> |

Game Console support

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

Features

Graphics 2 API

A Canvas type rendering API to draw textures, geometric shapes, text and SDF shapes (because we all know the best rectangles have rounded corners! :monocle_face: )

ECS

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.

UI

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.

Integrated Memory Allocator

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.

Documentation

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

Samples

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

Note

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.

Contribute

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