Test Page §

May 9th, 2026

Anchor Test §

Layout Diagram §

Memory allocation seems to be something many people struggle with. Many languages try to automatically handle memory for you using different strategies: garbage collection (GC), automatic reference counting (ARC), resource acquisition is initialization (RAII), and ownership semantics. However, trying to abstract away memory allocation comes at a higher cost than most people realize.

Most people are taught to think of memory in terms of the stack and the heap, where the stack is automaticallygrown for a procedure call, and the heap is some magical thing that you can use to get memory that needs to live longer than the stack. This dualistic approach to memory is the wrong way to think about it. It gives the programmer the mental model that the stack is a special form of memory Most architectures have register dedicated as a pointer to the stack, that is added because it is used frequently and pragmatically makes sense to do so. and that the heap is magical in nature.

Modern operating systems virtualize memory on a per-process basis. This means that the addresses used within your program/process are specific to that program/process only. Due to operating systems virtualizing the memory space for us, this allows us to think about memory in a completely different way. Memory is not longer this dualistic model of the stack and the heap but rather a monistic model where everything is virtual memory. Some of that virtual address space is reserved for procedure stack frames, some of it is reserved for things required by the operating system, and the rest we can use for whatever we want. This may sound similar to original dualistic model that I stated previously, however, the biggest difference is realizing that the memory is virtually-mapped and linear, and that you can split that linear memory space in sections.

Source: Ginger Bill - Memory Allocation Strategies - Part 1

User Space	Applications
	Libraries
Kernel Space	File Systems
	Inter Process Communication
	I/O and Device Management
	Fundamental process management
Hardware

Shader Code §

float sdf_circle(vec2 p, float r) {
  return length(p) - r;
}

float sdf_box(vec2 p, vec2 b) {
  vec2 d = abs(p) - b;
  return length(max(d, 0.0)) + min(max(d.x, d.y), 0.0);
}

CSS Inheritance Tree Example §

Node3D
- Projectile
- Entity
  - EntPlayer
  - EntWeedPeter
  - EntPhotoguy

ASCII Directory Tree Example §

├── zola.toml
├── content/
│   └── blog/
│       ├── _index.md
│       ├── first.md
│       └── second.md
├── sass/
├── static/
├── templates/
│   ├── base.html
│   ├── blog-page.html
│   ├── blog.html
│   └── index.html
└── themes/

GDScript Style Guide §

static func animate_sweep () -> void:

    var o: Hazard = Hazard.alloc(Enum.Id.ID_SWEEP_01);

    o.position = Vector3(0.0, 1.5, 0.0);

    Gb.scene.add_child(o);

    var time_full   : float = 0.45;
    var time_reveal : float = 0.2;
    var time_fade   : float = 0.2;

    var angle_start : float = -3.0;
    var angle_end   : float = 1.0;

    o.tween = Fn.create_parallel_tween();

    o.lifetime = time_full;

    # FADE

    o.mesh.transparency = 1.0;

    o.tween.set_trans(Tween.TRANS_LINEAR);

    o.tween \
        .tween_property(o.mesh, ^"transparency", 0.0, time_reveal);

    o.tween \
        .tween_property(o.mesh, ^"transparency", 1.0, time_fade) \
        .set_delay(time_full - time_fade);

    # ROTATE

    o.viz.rotation = Vec3.y(angle_start);

    o.tween.set_trans(Tween.TRANS_SINE);
    o.tween.set_ease(Tween.EASE_IN_OUT);

    o.tween \
        .tween_property(o.viz, ^"rotation", Vec3.y(angle_end), time_full);

Sokol Libraries §

sokol - Simple STB-style cross-platform libraries for C and C++, written in C.

typedef struct sg_image_usage {
    bool storage_image;
    bool color_attachment;
    bool resolve_attachment;
    bool depth_stencil_attachment;
    bool immutable;
    bool dynamic_update;
    bool stream_update;
} sg_image_usage;

C Style Guide

_SOKOL_PRIVATE MTLLoadAction _sg_mtl_load_action(sg_load_action a) {
    switch (a) {
        case SG_LOADACTION_CLEAR:       return MTLLoadActionClear;
        case SG_LOADACTION_LOAD:        return MTLLoadActionLoad;
        case SG_LOADACTION_DONTCARE:    return MTLLoadActionDontCare;
        default: SOKOL_UNREACHABLE;     return (MTLLoadAction)0;
    }
}

Ascii Block Rendering §

            (  o  o  )
┌────ooO───────(__)───────────────.
│      PAY ATTENTION TO THIS!     |
└──────────────────────Ooo────.   |
             |   |   |      __|   |__
             |   |   |     `.       .´
             |___|___|       `.   .´
             /_ 'Y' _\         `.´
            (___/ \___)

ImGui Conditial §

// Enumeration for ImGui::SetNextWindow***(), SetWindow***(), SetNextItem***() functions
// Represent a condition.
// Important: Treat as a regular enum! Do NOT combine multiple values using binary operators! All the functions above treat 0 as a shortcut to ImGuiCond_Always.
enum ImGuiCond_
{
  ImGuiCond_None          = 0,        // No condition (always set the variable), same as _Always
  ImGuiCond_Always        = 1 << 0,   // No condition (always set the variable), same as _None
  ImGuiCond_Once          = 1 << 1,   // Set the variable once per runtime session (only the first call will succeed)
  ImGuiCond_FirstUseEver  = 1 << 2,   // Set the variable if the object/window has no persistently saved data (no entry in .ini file)
  ImGuiCond_Appearing     = 1 << 3,   // Set the variable if the object/window is appearing after being hidden/inactive (or the first time)
};

Types of Code Reuse §

          Layer                     Engine                     Component
          ‾‾‾‾‾                     ‾‾‾‾‾‾                     ‾‾‾‾‾‾‾‾‾
┌───────────────────────┐  ┌───────────────────────┐   ┌───────────────────────┐
│          YOU          │  │        Reused         │   │          YOU          │
└────┬─────────────┬────┘  └───┬──▲────────┬──┬────┘   └───┬──▲────────┬──┬────┘
     │             │           │  │        │  │            │  │        │  │
┌────▼────┐        │       ┌───▼──┴──┐     │  │        ┌───▼──┴──┐     │  │
│ Reused  │        │       │   YOU   │     │  │        │ Reused  │     │  │
└────┬────┘        │       └─────────┘     │  │        └─────────┘     │  │
     │             │            ┌──────────┘  │             ┌──────────┘  │
┌────▼────┐   ┌────▼────┐  ┌────▼────┐   ┌────▼────┐   ┌────▼────┐   ┌────▼────┐
│ Service │...│ Service │  │ Service │...│ Service │   │ Service │...│ Service │
└─────────┘   └─────────┘  └─────────┘   └─────────┘   └─────────┘   └─────────┘

Source: Casey Muratori - Designing and Evaluating Reusable Components - 2004

As I previously stated, the monistic model of memory is the preferred model of memory (on modern systems). This generational approach to memory orders the lifetime of memory in a hierarchical fashion. You could still have pseudo-permanent memory within a transient allocator or a scratch allocator, as the difference is thinking about the relative usage of that memory with respect to its lifetime. Thinking locally about how memory is used aids with conceptualizing and managing memory — the human brain can only hold so much.

The same localist thought process can be applied to the memory-space/size of which I will be discussing in later articles in this series.

I'm centered =D
       o
      /|\
      / \

     I'm right aligned
 o/
/|
/ \