Skip to content

Instantly share code, notes, and snippets.

@vurtun
vurtun / fibers.c
Last active February 27, 2023 05:37
#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <stdint.h>
#include <assert.h>
#include <string.h>
#define streq(a, b) (!strcmp((a), (b)))
#ifndef __USE_GNU
#define __USE_GNU
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <assert.h>
#include <string.h>
#define streq(a, b) (!strcmp((a), (b)))
#ifndef __USE_GNU
#define __USE_GNU
#endif
#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
static void
Quat_FromEulerXYZ(float *euler_quat, float x, float y, float z)
{
float sx = (float)sin((double)(x * 0.5f));
float sy = (float)sin((double)(y * 0.5f));
float sz = (float)sin((double)(z * 0.5f));
float cx = (float)cos((double)(x * 0.5f));
float cy = (float)cos((double)(y * 0.5f));
float cz = (float)cos((double)(z * 0.5f));
@vurtun
vurtun / Library writing.txt
Created September 12, 2016 11:20
Library writing
LIBRARY WRITING REFERENCE LIST
===============================
1.) Designing and Evaluating Reusable Components (Casey Muratori: http://mollyrocket.com/casey/stream_0028.html)
----------------------------------------------------------------------------------------------------------------
_THE_ reference on API design up to this day on the internet. Nobody should write a library without having seen this.
I come back to this talk every N number of weeks it is that good.
2.) stb_howto (Sean Barrett: https://github.com/nothings/stb/blob/master/docs/stb_howto.txt)
--------------------------------------------------------------------------------------------
Sean Barretts single header libraries (https://github.com/nothings/stb) was the first time for me that I came across
/* Lightweight module based templates in standard C
===================================================
This is a proof of concept example of lightweight module based templates in C and
is loosely based on https://gist.github.com/pervognsen/c56d4ddce94fbef3c80e228b39efc028 from Per Vognsen.
While his approach (at least as far as I understood) is based on a python script to generate
the .h/.c files for you is this implementation contained in one single header file.
This is an outline to show how you can use the single header approach
and bend it to its absolute extrems. I tend to write specialized datastructures
for most of my problems but sometimes it happens that I have to use a particular

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
vurtun / gui.md
Last active October 4, 2023 15:44

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

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