DEV Community: Kapendev

Avoiding The GC in D: Stack, Buffers & Arenas

Kapendev — Sat, 09 May 2026 12:07:08 +0000

It's common to see new D users talking about @nogc and -betterC when discussing Manual Memory Management (MMM).
In a way, it makes sense.
Both are closely related to it based on their names.
One of them is literally called "no GC."

This might sound strange given their names, but neither @nogc nor -betterC is actually MMM.
They don't tell you how memory is allocated or when allocation happens.
A @nogc function could allocate or it could not.
What they do tell you is that one type of allocator, the GC, is not being used.
That only rules out one allocator.

The TL;DR is that both of those features are compiler-enforced GC restrictions with:

@nogc: also being part of the type system.
-betterC: also removing the D runtime.

In this post, I will skip over -betterC since removing the D runtime is a topic of its own.
I'll go over how to do manual memory management in D and how to avoid the GC without fighting the language.

Stack Memory

Let's start with the stack.
It's the simplest option to use and is always available.
To use it, you define a static type and create an instance of it on the stack:

void main() {
    alias StringData = char[64][4]; // The type.
    StringData stringData = void;   // The instance.
}

In the code above, the program can store 4 strings containing up to 64 characters each.
The = void part tells the compiler to not default initialize the string data because it will be initialized later as needed.

For example:

import std.stdio;

void main() {
    alias StringData = char[64][4];
    StringData stringData = void;

    auto text = stringData[0][0 .. 3]; // Create a string.
    text[] = "Hi!";                    // Initialize the string.
    writeln(text);                     // Use the string.
}

The variable text points to the 3 first bytes of stringData and they are used to print Hi! with writeln.
A similar pattern in game development is creating temporary strings for things like entities or levels.
With the trick above, we can generate level names without dynamically allocating:

import std.stdio;

void main() {
    alias StringData = char[64][4];
    StringData stringData = void;

    auto level = 68;
    auto name = stringData[0][0 .. 8];
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);

    writeln(name); // Output: level_68
}

That's nice.
There is no need to free any memory here because the stack will handle it automatically.
The natural next step is to wrap the string generation part of the code into a function so the main function is less noisy:

import std.stdio;

void main() {
    auto level = 68;
    auto name = level.toLevelName();
    writeln(name);
}

const(char)[] toLevelName(int level) {
    alias StringData = char[64][4];
    StringData stringData = void;

    auto name = stringData[0][0 .. 8];
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

You might notice, however, that the output is now not correct.
This happens because the returned slice points to memory owned by the callee's stack frame, which becomes invalid once the function returns.
So, how do we fix that if we want to be able to return some temporary data from a function?

Static Buffers

The solution is static buffers.
They are valid for the entirety of the program's lifetime, meaning we can pass them around without any issues.
It's also important to note that static variables in D are thread-local by default, so each thread gets its own buffer:

import std.stdio;

void main() {
    auto level = 68;
    auto name = level.toLevelName();
    writeln(name);
}

const(char)[] toLevelName(int level) {
    alias StringData = char[64][4];
    static StringData stringData = void; // <-- The fix.

    auto name = stringData[0][0 .. 8];
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

There is still one issue though: only one of the 4 static strings is being used.
This means that every call to toLevelName will always return the same data, potentially invalidating the memory of any variable that holds a result of that function.

For example:

import std.stdio;

void main() {
    auto name1 = 1.toLevelName();
    auto name2 = 2.toLevelName();
    writeln(name1); // Output: level_02
    writeln(name2); // Output: level_02
}

const(char)[] toLevelName(int level) {
    alias StringData = char[64][4];
    static StringData stringData = void;

    auto name = stringData[0][0 .. 8];
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

Both name1 and name2 should have different values, yet they are the same because of the mentioned issue.
To avoid this, a new static variable needs to be created that changes the current string used by the toLevelName function:

import std.stdio;

void main() {
    auto name1 = 1.toLevelName();
    auto name2 = 2.toLevelName();
    writeln(name1); // Output: level_01
    writeln(name2); // Output: level_02
}

const(char)[] toLevelName(int level) {
    alias StringData = char[64][4];
    static StringData stringData = void;
    static ubyte stringDataIndex = 0; // <-- Fix 1.

    stringDataIndex = (stringDataIndex + 1) % stringData.length; // <-- Fix 2.
    auto name = stringData[stringDataIndex][0 .. 8]; // <-- Fix 3.
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

This works because stringDataIndex cycles through the 4 available strings in order, wrapping back to the beginning once it reaches the end.
This is called a circular buffer, and it is a common pattern for managing a fixed pool of temporary data without dynamic allocation.

Static buffers work well for short-lived data with a known maximum size, but they force the function to manage its own memory.
What if you don't want that?

Passing Memory

One solution is to pass the memory to it instead:

import std.stdio;

void main() {
    char[256] buffer = void;
    auto name1 = 1.toLevelName(buffer[0 .. 16]);
    auto name2 = 2.toLevelName(buffer[16 .. 32]);
    writeln(name1); // Output: level_01
    writeln(name2); // Output: level_02
}

const(char)[] toLevelName(int level, char[] data) {
    auto name = data[0 .. 8];
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

The buffer here is a stack allocation in main, but it could come from anywhere.
It could be memory from malloc or even the GC.

This example works, but manually tracking which slice of the buffer is free like the code above quickly becomes tedious.
That's the job of an allocator.

Allocators

At this point we are manually tracking regions in a buffer.
Allocators exist to automate exactly that.
For this code, it makes sense to make an arena/bump allocator.
An arena allocator works by keeping a pointer into a buffer and bumping it forward with each allocation.
When the buffer is full, it returns null.

The arena will look like this:

struct Arena {
    char[] buffer;
    size_t offset;

    char[] makeChars(size_t size) {
        if (offset + size > buffer.length) return null;
        auto result = buffer[offset .. offset + size];
        offset += size;
        return result;
    }
}

Then update toLevelName to use it:

const(char)[] toLevelName(int level, ref Arena arena) {
    auto name = arena.makeChars(8);
    if (name.length == 0) return null;
    name[0 .. 6] = "level_";
    name[6] = cast(char) ('0' + (level / 10) % 10);
    name[7] = cast(char) ('0' + level % 10);
    return name;
}

And finally update main:

void main() {
    char[256] buffer = void;
    auto arena = Arena(buffer);
    auto name1 = 1.toLevelName(arena);
    auto name2 = 2.toLevelName(arena);
    writeln(name1); // Output: level_01
    writeln(name2); // Output: level_02
}

The arena owns the buffer and handles the slicing.
To free all the memory at once, just reset the offset back to zero.

Abstracting Allocators

Like every solution before, passing allocators around has also an issue: they color functions, meaning a specific allocator must be passed to every function that needs it.
A way to somewhat avoid this is by abstracting allocators behind one or more function pointers.
That mechanism is referred to as an allocator API.
It is slower than using them directly, but avoids specialization.
Whether that tradeoff makes sense depends on the situation.

If you need one, below is the allocator API of Joka that can be easily copy-pasted into a project:

struct MemoryContext {
    void* allocatorState;
    AllocatorReallocFunc reallocFunc;

    void* malloc(size_t alignment, size_t size, const(char)[] file, size_t line) {
        return reallocFunc(allocatorState, alignment, null, 0, size, file, line);
    }

    void* realloc(size_t alignment, void* oldPtr, size_t oldSize, size_t newSize, const(char)[] file, size_t line) {
        return reallocFunc(allocatorState, alignment, oldPtr, oldSize, newSize, file, line);
    }

    void free(size_t alignment, void* oldPtr, size_t oldSize, const(char)[] file, size_t line) {
        reallocFunc(allocatorState, alignment, oldPtr, oldSize, 0, file, line);
    }
}

alias AllocatorReallocFunc = void* function(void* allocatorState, size_t alignment, void* oldPtr, size_t oldSize, size_t newSize, const(char)[] file, size_t line);

What About The GC?

Now that we covered the basics, let's focus on a common question: how do I know that the GC is not being used without @nogc?
There are some things to be aware of.

The first is array literals.
They allocate when assigned to slices because the slice by itself can't store the data:

// Allocates.
int[] a = [1, 2, 3];

// Does not allocate.
int[3] b = [1, 2, 3];

The second is delegates that capture variables from an outer scope.
They allocate because the captured variables need to outlive the current stack frame:

// Allocates.
auto offset = 10;
auto a = (int x) => x + offset;

// Does not allocate.
auto b = (int x) => x + 10;
auto c = function(int x) => x + 10;

The third is the ~ operator.
It allocates sometimes because it needs to create a new array at runtime:

// Allocates.
import std.conv;
auto a = "level_" ~ to!string(9);

// Does not allocate.
enum b = "level_" ~ to!string(9);

One way to detect implicit allocations like the ones mentioned above is by using the -vgc flag:

dmd -vgc app.d
# Or: ldc2 --vgc app.d
# Or: gdc -ftransition=nogc app.d

Example output:

[alex/Documents/code] dmd -vgc app.d 
app.d(31): vgc: array literal may cause a GC allocation
app.d(33): vgc: operator `~` may cause a GC allocation
app.d(28): vgc: using closure causes GC allocation

For functions in precompiled code not covered by -vgc, it's usually easy to tell by reading the code.
Take writeln as an example: it might allocate if you pass a number (it doesn't, just assume), but it will not if you pass a string, since there is nothing to convert to a string.

writeln is also a great example of why you should not mark everything as @nogc. Its job is simply to print text. It shouldn't care whether the toString method of a type allocates with the GC or not.
That is a decision the caller has to make, and for templated functions the compiler can infer @nogc (can't with writeln because of exceptions).

Because @nogc is part of a function, it becomes an API contract the moment a function accepts a user-provided callback.
That is a strong constraint, so it should preferably appear where it genuinely makes sense: at API boundaries, or for self-contained functions like makeChars and toLevelName that never touch the GC.
A question to ask before using @nogc is whether this guarantee needs to be enforced by the compiler, or whether a comment could do a similar job.

A couple of additional notes worth mentioning:

Note 1: Debugging @nogc functions can be tricky since writeln is not allowed. A simple workaround is using debug statements:

void debugWriteln(A...)(A args) {
    import std.stdio;
    debug writeln(args);
}

@nogc
void myFunction() {
    debugWriteln("Something only for debugging.");
}

Note 2: The -profile=gc flag can be used to create a profilegc.log file.
I never needed it personally, but from what I understand it tracks what allocated at runtime rather than what could allocate.

Conclusion

Manual memory management in D does not require @nogc or -betterC.
As shown above, you can do a lot with just the stack, static buffers, and a simple arena allocator.

A basic table of what and when to use from the discussed topics:

Situation	Use
Temporary & self-contained	Stack
Needs to outlive function	Static buffer
Multiple callers & self-contained	Passed memory
Many allocations or bulk free	Arena

One last thing worth exploring is using MMM libraries like NuMem, Joka, or core.stdc.stdlib. NuMem is used in some D libraries, while Joka is a personal project of mine.

Parin Game Engine Devlog – October 2025

Kapendev — Tue, 28 Oct 2025 11:43:08 +0000

Welcome to the October 2025 devlog for Parin.

🫐 Backend Support

A lot of time this month went into adding support for multiple backends. By "backend," I mean the ability to swap the current platform layer, raylib, for a different one. This required some breaking changes to make everything work correctly and pushed Parin toward a more abstract design.

In practice, this means that every engine resource (Texture, Font, Sound, Viewport) is now only represented by an ID and the backend is responsible for what is will do with that ID. For example, Viewport as a structure no longer exists and you have to use something called a ViewportId. As with every ID before this change, you'll need to use one of the load* functions to obtain a new ID. A nice side effect of this system is that engine resources are safer to use (no state bugs, etc.) and the Parin API is simpler since there's only one way to do things.

The main benefit of this change is that Parin will be able to use something like SDL, PixelPerfectEngine, or even Godot as a platform layer in the future. In the case of Godot, it would take a lot of work because of how Godot works, but it's definitely possible. The Godot backend is on my "for fun" TODO list.

🍵 Deprecation Removal & Changes

Because of the changes mentioned above, I figured it was a good time to remove all the deprecated names and functions that had built up over time for backward compatibility. For example, the alias format for the fmt function no longer exists.

Loading functions also changed a bit. They now support absolute paths and always return a value directly, instead of sometimes wrapping it in an option/maybe type. If an error occurred while loading, then a "null" value is returned. To get more information about what kind of error happened, you can use the lastLoadOrSaveFault function. This is similar to how Godot handles errors and over time I have come to think it's a perfectly fine way of doing things, at least for game code.

The next big deprecation removal will come with version 0.2.0.

📦 No External Dependencies

After thinking about this for a long long long time, I decided it was finally the right moment to vendor every dependency Parin had. This means Parin can now be built simply by cloning the repository. No dependency management through DUB or Git is needed.

But why? Don't you like package managers?

It is not about liking or disliking package managers. I just prefer simple things. Being able to download Parin and use it right away feels great. Building is simpler, grepping is simpler, grokking is simpler, ... This change just makes everything nicer overall, for both DUB and no DUB users.

Don't worry, I'm not about to go on a "unstructured" package-manager rant like gingerBill or monkeyyyy.

🧭 Documentation

I went over some code in math.d, ascii.d, and engine.d, and refactored parts of them. Functions should now follow a more logical order in most places and a lot of code that previously lacked documentation comments now has them. Overall, this should make things much easier to understand.

The Parin cheatsheet also got an update. Its structure changed and now includes the first line of each function's documentation comment, making it easier to rely on it for quick information on how to do things.

🌤️ What's Next

Well, no idea. Parin is in a good state right now. Mostly bug-free and provides a nice experience for the types of games I want to make. The thing I'll probably focus on next is Parin UI, the WebAssembly scripts, and maybe shaders. The next Parin devlog will likely take a bit longer to release.

That's mostly it. If you try Parin out, let me know what you think in the GitHub discussions.

Parin Game Engine Devlog – September 2025

Kapendev — Thu, 25 Sep 2025 12:20:29 +0000

Welcome to the September 2025 devlog for Parin.

🎨 New Palettes

This month, 8 predefined color palettes were added. Two are inspired by the Game Boy and NES, while others bring in Linux nerd stuff like Gruvbox.

HexPalette!4 gb4 = [ .. ];
HexPalette!8 nes8 = [ .. ];
HexPalette!16 gruvboxDark = [ .. ];
HexPalette!16 gruvboxLight = [ .. ];
HexPalette!16 oneDark = [ .. ];
HexPalette!16 oneLight = [ .. ];
HexPalette!16 solarizedDark = [ .. ];
HexPalette!16 solarizedLight = [ .. ];

On top of that, there is now a helper function to parse palettes from a CSV file called csvRowToPalette. Monkeyyy is happy.

⚡ Drawing Go Brrr

A version called ParinSkipDrawChecks was added for situations where speed matters more than safety. Invalid draw values will crash your game, so use it only if you know what you are doing.

This version also disables debug shapes when attempting to draw empty (not loaded) resources. If you are not familiar with debug shapes, here's how they look:

With loaded resources

Without loaded resources

You can find the game here.

🗂️ Frame Allocator & Better Containers

The engine now provides a frame allocator for temporary memory. Allocations from it only live for the current frame and are automatically cleared at the end. This is useful for scratch data like strings or small objects created every frame without worrying about freeing them.

void* frameMalloc(Sz size, Sz alignment);
void* frameRealloc(void* ptr, Sz oldSize, Sz newSize, Sz alignment);
T* frameMakeBlank(T)();
T* frameMake(T)(const(T) value = T.init);
T[] frameMakeSliceBlank(T)(Sz length);
T[] frameMakeSlice(T)(Sz length, const(T) value = T.init);

The engine already uses this allocator internally for functions like loadTempText and prepareTempText. Alongside this, the built-in containers got more generic in terms of allocation strategy. Previously, they only supported heap allocation. Now they can also be stack-allocated or backed by external memory.

One practical example is tile map layers in the map module, which now use fixed-sized containers:

// Fixed-sized container.
alias TileMapLayerData = FixedList!(short, maxTileMapLayerCapacity);
// Fixed-sized container.
alias TileMapLayer = Grid!(TileMapLayerData.Item, TileMapLayerData);
// Dynamic container.
alias TileMapLayers = List!TileMapLayer;

🧩 Memory Tracking

Parin got a lightweight memory tracking system that can detect leaks or invalid frees in debug builds. By default, leaks will be printed at shutdown only if they are detected.

bool isLoggingMemoryTrackingInfo();
void setIsLoggingMemoryTrackingInfo(bool value, IStr filter = "");

Example output:

Memory Leaks: 4 (total 699 bytes, 5 ignored)
  1 leak, 20 bytes, source/app.d:24
  1 leak, 53 bytes, source/app.d:31
  2 leak, 32 bytes, source/app.d:123

This isn't strictly a Parin feature. It comes from Joka, the library Parin uses for memory allocations. Anything allocated through Joka is automatically tracked. You can check whether memory tracking is active with static if (isTrackingMemory), and if it is, you can inspect the current tracking state via _memoryTrackingState.

_memoryTrackingState is thread-local, so each thread has its own separate tracking state. When you look at the state or summary, remember that it's primarily a debug tool. In general, this information is normal in debug builds and doesn't indicate an error.

Some leaks can be ignored with the ignoreLeak function like this:

// struct Game { int hp; int mp; }
// Game* game;
game = jokaMake!Game().ignoreLeak();

This feature might seem simple, but it can provide valuable insight into what's happening with memory. For example, it helped me cut the number of heap allocations in one part of the engine from 19 down to 9.

📦 Extras Collection

A new extras collection of optional libraries was added. At the moment, it only includes microui, but more may be added over time. This is mostly a batteries included thing and lets internal Parin code use libraries without any dependencies that need to be downloaded.

🎚️ Easing

Two new structs were added:

Tween: Eases between two float values
SmoothToggle: Handles smooth transitions between two states, usually on/off.

Here is a basic example that creates a basic transition effect with the SmoothToggle type:

auto color = cyan;
auto state = SmoothToggle();

bool update(float dt) {
    if ('q'.isPressed) state.toggle();
    auto value = smoothstep(-resolutionHeight, resolutionHeight, state.update(dt));
    if (state.isAtEnd) {
        state.toggleSnap();
        color.r = cast(ubyte) (randi % 255);
        color.g = cast(ubyte) (randi % 255);
        color.b = cast(ubyte) (randi % 255);
    };
    drawRect(Rect(0, value, resolution), color);
    return false;
}

Both are designed to be small in size, so they can be easily iterated in an animation array, for example. Tween is 20 bytes and SmoothToggle is 8 bytes. Tween also supports vectors through the types Tween2, Tween3 and Tween4.

🖨️ Faster Formatting & Printing Improvements

Projects should compile faster thanks to a simpler fmt implementation. The fmt template, used for string formatting, is now just 8 lines of code and delegates all the work to a non-template function called fmtIntoBufferWithStrs.

A new struct called Sep was also added as a handy separator marker for printing functions. For example:

// Will print: "1 2 3 Go!"
println(Sep(" "), 1, 2, 3, "Go!");

This allows you to easily control separators when printing, which is great for quick debugging.

🐇 Bunnymark

It's not a classic "bunnymark." More like "wormmark." I put together a quick test to see how well the current physics system works, and the results seem fine. The test runs with 30,000 worms, and each one is a physics object moving around the room. It's close to 60 FPS on a Ryzen 3 2200G with 16 GB of memory.

You can find the code for the game here. Just change the appendWorm function.

📍 Fin

That's mostly it. If you try Parin out, let me know what you think in the GitHub discussions.

Please read my rant.

Kapendev — Tue, 02 Sep 2025 12:02:42 +0000

Kapendev

Sep 1 '25

Raylib Is Great for Small Games, Someone Said Again...

#gamedev #programming #raylib #odinlang

Comments 1

3 min read

Raylib Is Great for Small Games, Someone Said Again...

Kapendev — Mon, 01 Sep 2025 23:57:13 +0000

I keep hearing this line, mostly on the Odin Discord server. What is that? It's a bunch of nerds who like a programming language called Odin.

Now, why am I even writing a blog about this stupid line that makes no sense anyway? Good question. The answer is: because someone has to tell nerds when they are being nerds, so they stop nerding out so hard.

This is me being nice, actually. I'm just trying to make the Odin Discord server a better place.

The Line

Every time someone says it, it sounds like they are giving raylib a compliment. But it's not really a compliment, is it? Maybe sometimes, but not in the Odin server. Remember, we are dealing with evil nerds here. It's more like a backhanded "good job, I guess."

But it is great for small games. What's wrong with saying that? - gingereebill

The problem isn't that raylib can't be used for small games. Of course it can. It's actually really easy to make games with it. The problem is the way people say it as if that's all it's good for. Like raylib is just a toy library you will eventually grow out of once you are ready for the "real stuff."

To be clear, "simple games" isn't an insult, to the games or to raylib. - barizodin

Yeah, I'm used to that same line from game engine people. It's just a nice thing to say.

Of course you can use it for non-learning and slightly less simple games. But it was created for learning - karlzylonski

And? That's irrelevant to what raylib actually is. It has a lot of solid, well-written code. The creator can use it however he wants, but that doesn't limit anyone else. Lua, for example, was created to be a nice config file language, and look how it's used now. Also, thanks for the "slightly less simple games" upgrade. I get it, not an insult, just like the line above.

You are just complaining and trying to have strong opinions. - karlzylonski

Bro, who is having strong opinions here? Also why is this blog becoming like a Discord chat?

Strong Opinions

The Odin server has more graphics devs, so it makes sense they look at anything even slightly high-level as "simple" or "just for learning." That's the culture. But that context doesn't make the line true. It just means you are hearing it from people who would rather make their own "better" abstractions. And that's fine. I'm waiting to see how Gordon2D (a library by gingereebill) and Karl2D (a library by karlzylonski) will evolve.

These people also assume raylib will always be used "as is." But that's not the case. If you need something different, you can just fork it and make the changes you want. There's really no serious problem you can't solve with a custom fork for your project.

By the way, just search "OOP" in the Odin Discord server. It's currently mentioned 2,716 times and counting. For comparison, the D Discord server has 1,331 mentions of OOP, and that's a language with OOP support. Odin is one of those no-OOP langs. Strong opinions, huh?

no, like, raylib is close to the ideal; its got allot of c apis nonsense, but still it is just a list of functions that are well named and has the right kind and ammount of docs - monkyyy

Me

Anyway, that's enough ranting. For what it's worth, I'm currently using raylib as the base for my own little game engine/framework/library (never cared about the distinction) called Parin. I might switch things up in the future, but right now raylib is perfect for what I need. If you are curious, here's the repo.

Worms Within - A bite-sized escape room game.

Conclusion

So yeah, raylib works. That's all that matters to me.