Skip to content

Instantly share code, notes, and snippets.

Avatar

lylejantzi3rd

View GitHub Profile
View jsn.c
enum jsn_type {
JSN_OBJ,
JSN_ARY,
JSN_NUM,
JSN_STR,
JSN_TRUE,
JSN_FALSE,
JSN_NULL
};
struct jsn_val {
@DanielVF
DanielVF / atc.nim
Last active Jan 28, 2020
Nim engine, no documentation
View atc.nim
import sets
import engine
import strutils
import math
# import log
type
Atc* = ref object of RootObj
available*: HashSet[Ship]
occupied*: seq[bool]
View multiple-patron-context.js
import React from 'react'
import { api } from 'ducks/user'
const MultiplePatronContext = React.createContext({
isMultiplePatronEnabled: false,
error: '',
})
export class MultiplePatronProvider extends React.Component {
@chrisnordqvist
chrisnordqvist / init.lua
Created Feb 14, 2018
My hammerspoon config
View init.lua
logger = hs.logger.new('main')
--- functions
function open(name)
return function()
hs.application.launchOrFocus(name)
if name == 'Finder' then
hs.appfinder.appFromName(name):activate()
end
end
@vurtun
vurtun / api.md
Last active Aug 6, 2020
API Design: Modular Data-oriented processes
View api.md

API Design: Modular Data-oriented processes (June-2017)

This is the second entry in my series about API design. While I wrote about granularity and request based APIs in my last post I want to write about API design and code architecture for modular data-oriented process this time. This is basically the write up of my findings while writing and finishing the core of my current GUI research quarks.

Actually sparking my interest for writing up my findings however was rasmusbarr@github (rasmusbarr@twitter) releasing his small data-oriented and SIMD-optimized 3D rigid body physics library. I noticed a lot of overlap in design between his physics and my GUI library and wanted to write up some general thoughts about what seems

View (im)gui.md

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

View gui.md

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

@bkaradzic
bkaradzic / why_i_think_immediate_mode_gui_is_way_to_go_for_gamedev_tools.md
Last active Oct 25, 2020
Why I think Immediate Mode GUI is way to go for GameDev tools
View why_i_think_immediate_mode_gui_is_way_to_go_for_gamedev_tools.md

Why I think Immediate Mode GUI is way to go for GameDev tools

Prerequisites

Before you continue, if you don't know what IMGUI is don't bother reading this post, just ignore it, don't write anything in comments section, etc. If you're curious about IMGUI see bottom of this post, otherwise continue whatever you were doing, this post it's not for you. Thanks!

If you know what IMGUI is, for context read following presentations and blog posts:

  • Insomniac’s Web Tools Postmortem
View api.txt
This is a brief comment on this article on API design principles:
https://gist.github.com/vurtun/192cac1f1818417d7b4067d60e4fe921
I've called that style of API a coroutine, iterator, state machine, push/pull or client/server API
depending on what seems most appropriate for the context, but they are all variants of the same idea.
It's particularly superior in many cases as an alternative to callback-based APIs, which are the more
common way of providing this kind of fine-grained interleaving between library code and user code.
Callbacks can still be superior in usability for context-free operations like memory allocation,
View API Design:Coroutine-APIs.md

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.

You can’t perform that action at this time.