vurtun

Graphical User Interfaces

For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.

Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.

The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small

vurtun

Graphical User Interfaces

Last time I wrote a little bit about my current GUI research progress. There are some things that were misunderstood so I want to clarify some fundamental design decisions and finally write up some current problems and their solutions.

First up I want to clarify a component is not another term for what is usually refered to as widget. Instead wigets in this implementation are made out of n >= 1 components. Components themself are just rectangles with attributes left, right, top, bottom, center_x, center_y, width and height some behavior flags and an optional surface to draw into. For example a scroll regions is made up out of at least three

vurtun

Gilbert–Johnson–Keerthi (GJK) 3D distance algorithm

The Gilbert–Johnson–Keerthi (GJK) distance algorithm is a method of determining the minimum distance between two convex sets. The algorithm's stability, speed which operates in near-constant time, and small storage footprint make it popular for realtime collision detection.

Unlike many other distance algorithms, it has no requirments on geometry data to be stored in any specific format, but instead relies solely on a support function to iteratively generate closer simplices to the correct answer using the Minkowski sum (CSO) of two convex shapes.

vurtun

This is a short post related to Opaque object representations from Our Machinery. I have to begin that my understanding of how Our Machineries tech is somewhat limit and it is currently rather late in the day, so please bear with me. As far as I understood how modules work is similar to how Quake 2 did their modules. A module has both a struct for export and one for import containing a number of function pointer. At load time the module gets a filled out import struct and fills out its own export struct with its own functions and returns it.

As for the allocators. I would have guessed tha

vurtun

/**
 * Advent of Code 2022
 * Day 2: Rock Paper Scissors
 * https://adventofcode.com/2022/day/2
 *
 * http://codercorner.com/Modulo3.htm
 * (Index+1)%3 = (1 << Index1) & 3
 */
#include <stdlib.h>
#include <stdio.h>

vurtun

vurtun

API Design: Coroutines APIs (Janurary-2017)

I am currently dealing with a lot of libraries at work. Both third party as well as libraries written or being currently in process of being written by me. I absolutely love writing and working with libraries. Especially if they present or bring me to either a new or different approach to solve a problem. Or at least provide a different view.

Over time I noticed however that quite regulary we had to decide that we cannot use a third party library. Often it is the usual reason.

vurtun

static void
qdiag(float *restrict qres, const float *restrict A) {
  /* Diagonalizer: http://melax.github.io/diag.html
    'A' must be a symmetric matrix.
    Returns quaternion q such that corresponding matrix Q 
    can be used to Diagonalize 'A'
    Diagonal matrix D = Q * A * Transpose(Q);  and  A = QT*D*Q
    The rows of q are the eigenvectors D's diagonal is the eigenvalues
    As per 'row' convention if float3x3 Q = q.getmatrix(); then v*Q = q*v*conj(q)
  */

vurtun

vurtun

/* ===========================================================================
 *
 *                                  LIBRARY
 *
 * =========================================================================== */
/*  Proof of Concept GUI:
 *  - PoC UI implementation in ~2.5kLOC of C89 (ANSI C)
 *      => Core solutions has no external dependencies (removing standard library dependency is trival)
 *      => Does not use or require any special language constructs or macro constructs just pointers and enums
 *  - Combines both "retained" and "immediate mode" UI by providing control over update frequency