DEV Community: Kapendev

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.