Firefly in the Dusk🌙

DuskEngine Devlog 4 - Asset Refcounting Edition

2026-03-04T00:00:00Z

A bunch of things happened on the engine side this past month or so, but asset refcounting is by far the biggest and most important of them all so I'll focus just on it.

I'll be working more on memory optimizations going forward because I'm planning to add web support as soon as possible and it would be pretty embarrassing to have, for a tiny scene, a very large bundle size as well as unreasonably large RAM and VRAM usage, even if the engine is in such an early state.

A first step that was easy to get out of the way, was to make sure assets don't stick around in RAM long after they've been used by whichever systems requested them.

A while back I made it so the AssetManager returns AssetHandles whenever loading an asset is requested:

class AssetManager final
{
    ...

public:
    template <typename TAsset>
    AssetHandle<TAsset> LoadAsset(const AssetId& assetId)

    ...
}

Only the AssetManager is allowed to create AssetHandles from scratch.

This extra layer of indirection will allow for things like async loading, for example: the asset handle could behave like a sort of Promise, though I have not yet implemented anything with regards to async loading.

It also allows for simpler error handling (the asset handle can have an error state set on it, in case loading the asset is impossible) and indeed, refcounting.

The matter, at first thought, seems fairly simple: each time an asset handle for a particular asset is generated, increment some counter. Each time it gets released, decrease said counter. When the counter reaches zero, the asset can be ejected from whatever cache contains it (when an asset is loaded, it gets added to a cache so subsequent loads return the cached version).

One thing I'm fairly sure I don't want, is to start ejecting assets whenever the last AssetHandle's destructor gets called. That sounds like a potential recipe for chaos and annoying debugging sessions.

It might also lead to unnecessary loads for the same asset, for example if in the same frame, system A loads an asset, uses it, then releases the handle, and later on system B also needs it, but since the asset has been released, a full reload is triggered.

It also means that the memory taken by assets that are truly not needed anymore in that frame, cannot be reused for other things. This is a problem if the size of the assets loaded in that frame, versus the RAM amount of the system, especially if no swap is in place, is out of balance. I won't treat this as a very likely scenario at the moment, but will keep it in mind as I go.

So for now, let's schedule asset cleanup as part of the engine's main loop, to make things more predictable and easier to change in the future.

First of all, the refcounting part:

class IAssetRefCounter
{
public:
    virtual void IncreaseRefCount(const AssetId& id) = 0;
    virtual void DecreaseRefCount(const AssetId& id) = 0;
};

This is an interface for something that will adjust refcounts for assets. AssetHandles get a pointer to such an instance when created by the AssetManager:

class AssetHandle
{
public:
    AssetHandle(const AssetId& assetId, IAssetRefCounter* refCounter) 
        : mAssetId(assetId), mRefCounter(refCounter)
    {
        mRefCounter->IncreaseRefCount(assetId);
    }

    // copy ctor, assignment operator and a bunch of other things
    // omitted

    virtual ~AssetHandle()
    {
        mRefCounter->DecreaseRefCount(mAssetId);
    }
}

So, increase refcount on construction, decrease on destruction. I am not going to paste the whole class in here because who knows what issues it currently has and I wouldn't want to pass them to someone else 🙂

The concrete refcounter looks like this:

class AssetRefCounter : public IAssetRefCounter
{
public:
    AssetRefCounter();

    // these go through that vector below and alter or insert the
    // refcount for that asset
    void IncreaseRefCount(const AssetId& id) override;
    void DecreaseRefCount(const AssetId& id) override;
    void EraseAllZeroRefCountEntries();

    template <typename TCallback>
    void IterateZeroRefCountEntries(TCallback cb)
    {
        for (const auto& p : mAssetAndRefCount)
        {
            if (p.second == 0)
            {
                cb(p.first);
            }
        }
    }
private:
    std::vector<std::pair<AssetId, unsigned int>> mAssetAndRefCount{};
};

The AssetManager creates one at initialization time.

The vector of pairs of asset IDs and refcounts is likely not the fastest implementation, but I don't think it's going to be an issue anytime soon.

Then, at the end of each frame, the engine calls AssetManager::OnFrameEnd which does this:

void AssetManager::OnFrameEnd()
{
    mRefCounter.IterateZeroRefCountEntries([this](const AssetId& toRelease) {
        mAssetCaches.EraseFromAnyCache(toRelease);
        });

    mRefCounter.EraseAllZeroRefCountEntries();
}

I had to go back and fix some sloppy coding here and there, where instead of loading an asset, getting just the info the system needed and storing it for later, I was (re)loading the asset each time that info was needed. This manifested itself as a lot of asset reloads in a short amount of time.

Some extra functionality that I omitted from the refcounter class is iteration over non-zero refcount assets, which is used to list the assets that have active handles, in the editor, in order to spot any leaks.

And that's about it. I think this is a good start to build upon.

I have a feeling my next memory-related optimization will be to finally compress textures, it's long overdue 🙂

DuskEngine Devlog 3 - Slow December (and January) Edition

2026-01-28T00:00:00Z

December and January were fairly slow when it comes to adding features or improvements to the engine. The few changes that were made were small in effort and size, but they will in time have a large impact.

Upgraded to SDL3

Upgrading from SDL2 to SDL3 was quite quick and straightforward, especially since the devs made it so compile errors give you hints as to what you need to do to migrate the code.

The upgrade was done initially as a peace of mind thing, to ensure access to the latest features and to have compatibility with future platforms.

It turns out, however, that SDL3 has a pen tablet API builtin, and thus I was able to add pen pressure support for terrain painting:

Using pen pressure to adjust the strength of the painting, note the small indicator on the bottom left

I was looking into what I'd have to do using platform native APIs when I had a random thought: what if SDL3 has something for pen tablets too? And I'm glad I checked because it only took a few lines of code to make it work:

void DuskRawInput::ProcessPenEvent(const SDL_Event& e)
{
    if (e.type == SDL_EVENT_PEN_AXIS)
    {
        if (e.paxis.axis == SDL_PEN_AXIS_PRESSURE)
        {
            mPenPressure = e.paxis.value;
        }
    }
}

The code will get more complex as more features get added, but at this point in time, just keeping track of the pressure, and mixing mouse and pen events together, works well enough.

Added FMOD support

I've been curious to try FMOD Studio for a couple of years now and I made the switch from SoLoud to FMOD this month. The switch has large implications when it comes to how audio works in the engine, especially on the gameplay scripting side as it needs to be aware of FMOD Studio events and parameters.

An event I made that provides background sound for an electric lamp. It uses a parameter called MagicalInterference. In-game, when magic stuff is near the light, this parameter value, which ranges from 0.0 to 1.0, is altered to make the sound more intense

Management of the raw audio files (.ogg, .wav etc.) is now handled by FMOD Studio, which builds bank files out of all raw audio files as well as all the events and parameters that were created in the FMOD project — these bank files are now the actual audio assets as far as DuskEngine is concerned. Besides being used at gameplay time, the editor also reads them to build the list of events and parameters, to provide intellisense in Lua:

-- it generates such code.
-- strings like "event:/ElectricLampBuzzLoop" come from
-- the bank files. When this script gets executed,
-- it automatically queries for the event and param IDs
-- so as to not involve strings when triggering sounds.
ElectricLampBuzzLoop = {
    Id = Engine.GetAudioEventId("event:/ElectricLampBuzzLoop"),
    Params = {
        MagicalInterference = {
            Id = Engine.GetAudioEventParamId(
                "event:/ElectricLampBuzzLoop", 
                "MagicalInterference"
            ),
        },
    },
}

Scripts can then:

audioSource:PlayEvent(ElectricLampBuzzLoop)

-- and
audioSource:SetActiveEventParam(
    ElectricLampBuzzLoop.Params.MagicalInterference,
    0.5
)

-- and so on.

I'm excited to see what other cool stuff I'll be able to do on the audio side in the future. With FMOD Studio it does seem like the sky's the limit.

While this is all that's noteworthy on the engine side, there has been a ton of work on the gameplay side, including the implementation of fun activities like fishing and cooking, as well as skills for said activites, with XP and level ups and all the cool things.

It's all (mostly) too placeholder-y to show at the moment, but I'll post more updates soon.

An old preview of the cooking activity can be seen here.

BTW, I uploaded the stove model to OpenGameArt here.

Thanks for reading!

For any questions or feedback, find me on Bluesky

Firefly in the Dusk🌙

DuskEngine Devlog 2 - Entirely too much navmesh I've had enough edition

2025-12-05T00:00:00Z

The previous month no navmeshing happened even though it should have, this month so much happened I've had enough. There's more than just navigation to talk about however, so let's get to it.

Navmesh & Pathfinding

I started out using Recast for this, and for a while things went approximately well, especially because of Ravbug's sample which provided a nice starting point.

In order to have obstacle support you need to use a tiled navmesh rather than a basic one, and after days of trying to figure out which of the bazillion parameters Recast expected weren't right (the navmesh was always either broken or wrong in some subtle way), or if it was my geometry causing issues, I decided I have better things to do with my time, so I put together a quick grid-based solution instead.

It needs a lot more work, but it's a starting point. Characters are able to pathfind anywhere in the scene and I can prototype gameplay.

NavPlane entities define the areas that are meant to be walkable:

In this image the NavPlane normally covers the entire floor, but I made it smaller 'cause it's easier to see

Entities with the NavCarver component dig holes into the NavPlanes

The NavPlanes themselves are not grids, there is only one global (infinite) grid, and it's the parts of it that are covered by navplanes that are considered for pathfinding. Indeed, this means the objects in the scene need to be more or less aligned to this infinite grid, to make efficient use of the space when pathfinding.

At the end a NavGrid object gets built - it's the thing that gets queried for paths and updated for obstacles. It is built by taking all the information from NavPlanes and putting it together.

Dynamic obstacles such as doors are also working

Sphere is the only obstacle shape supported right now, for the door a box would be better but that will be implemented sometime later.

I'm not sure if in the future I'll still be using grids. I know for sure I'll be forced to add an extra dimension once buildings with multiple floors are required. This will likely happen next year. In that case NavPlanes would become NavVolumes or NavCubes, and rather than a 2D grid I'll likely deal with 3D voxel space. Agent height would also suddenly matter.

Dynamic obstacles are important (doors, or placing boxes or other obstacles in front of doors, stuff like that), and grids and their kin make supporting them extremely simple. Navmeshes would require rebuilding the parts that overlap with the obstacles, which is much more expensive than updating some flags on a grid.

I'm using a basic A* implementation to pathfind in the grid at the moment.

OK, enough about pathfinding. The rest of the cool new things follow:

Extra vegetation system features

DuskEngine features a vegetation system with which you can place vegetation patches in a scene. A vegetation patch is essentially a rectangle in which vegetation (meshes that sway in the "wind" and get pushed away by volumes such as characters) get spawned. You can use a brush to hide or show some of the spawned plants.

It works like this...

Up until now, grass and flowers were the only use case, so the vegetation system didn't need much in the way of shadows (it kinda made the grass look very crowded actually).

I modeled some cattail meshes and also made the system support shadowcasting vegetation. Grass still doesn't cast any shadows, but cattail needs to because it's large and looks weird without shadows.

The Cattail

Asset importing/cooking/baking made nicer

The following is only relevant when running the engine editor.

When something wants to load an asset, the asset manager first checks if there's a pre-baked version of the asset. If there isn't, or if it's outdated (because the source file changed since it was baked), it triggers a re-bake.

Because this is done on-demand, it introduces stuttering as new stuff comes into view, or presents a black screen for a pretty long time when a scene is first loaded, assuming for example that the entire asset cache has been cleared.

I made the editor first check that everything's properly pre-baked before even trying to give the engine instance something to do:

I love this dialog, it looks so legit

Showing this dialog wasn't the only reason I did it though. A big feature that the asset manager is missing is async asset loading.

Having this initial reimport step, before anything interesting even starts to happen, gives me a place where I can experiment with async loading without risk of breaking any of the existing functionality.

After I figure out what works and what doesn't, I can look into updating parts of the engine to benefit from async loading.

This will happen sometime in the future, as it's not necessarily high priority right now.

Making Lua gameplay scripting a bit nicer

Errors raised in gameplay Lua scripts used to crash the engine entirely, and I used to restart the whole thing after changing a script, in order to get it reloaded (or rebaked 😝).

Errors are now logged appropriately and the engine stays running. There's also a file watcher that evicts scripts that changed from the cache, so when they're next requested, they're in their latest version.

LOD vertex deduplication

LODs have been supported in the engine for a while now, but each LOD level was treated as an entirely separate mesh. This worked fine, but in most cases there is a very large overlap between the vertices in a lower LOD and those in the higher LODs, which means the same vertices get put into VRAM multiple times, which is wasteful.

So now as part of the mesh bake process, the engine will go through the lower LODs of that particular mesh and merge them with the original, while avoiding duplicated vertices. Essentially, creating one big buffer with verts, and a big buffer containing the concatenated indices for the original and lower LOD meshes.

That's it

That's about it for this month's devlog. I'm continuing work on pathfinding and steering behaviors for NPCs, among other things which I'll show on the next entry and on my bsky. See you next month!

For any questions or feedback, find me on Bluesky

Firefly in the Dusk🌙

DuskEngine Devlog 1 - Mostly Physics Edition

2025-11-09T00:00:00Z

In the previous entry I said that I'd be working on navmeshes, but something must have happened because I switched to physics for a while.

In any case, here are all the new and noteworthy things.

Primitive Colliders

Jolt has lots of features but the engine needs to have its own functionality that wraps it, which takes some time to write.

To save on implementation time, up until now, physics objects (which is what DuskEngine calls rigidbodies) were limited to a single collider. Said collider had to be a component on the same entity as the physics object component, and it had to be a mesh collider, either convex or regular.

As levels are starting to get larger and filled with more complex geometry such as buildings, I've added support for primitive colliders such as boxes and spheres, and now I also aggregate all colliders in the hierarchy of an object. This makes it so a physics object can have as many colliders as needed.

Three primitive colliders attached to a physics object. The visualization needs some more work...

The primitive colliders will also come in handy for objects that move, as they'll be much faster to check for collisions, and I remember somewhere I placed a hack to make convex mesh colliders work in such a context, I'll finally be able to delete said hack.

Physics Layers

Yet another important feature that DuskEngine finally gained.

There are eight (might tweak this number) available physics layers to assign objects to, and masks can be used when e.g. casting rays or shapes. A layer collision matrix is editable in the project settings, it decides which pairs of layers can collide.

This project settings window is also a recent addition

The reason I added layers now was because I wanted to improve the third person camera, so that the player cannot accidentally push it inside the level geometry.

Raycasting provided a good starting point (casting rays to see if there's an obstacle in the way), but it quickly became clear that not every piece of level geometry is equal in this respect. For example, I definitely want to tweak the camera position if there's a large building in the way, but if it's a fence, even if most of the player's character is covered by it, I think the camera could stay in place.

My current idea to handle this is to have a separate set of colliders exclusively for this purpose, essentially describing the bounds within which the camera can exist. Their parent objects are set on the CameraBounds layer which does not collide with anything, as it's only there for raycasting purposes.

The camera won't go through the building

Just this is insufficient to handle arbitrary level designs however so it's something I'll tweak as I go, but this is as good a starting point as any.

I have also updated some of the existing scripts so they make use of layers. For example, some spell effects that cast shapes to check if they hit anything, now exclusively check the Characters layer.

This also reduces the data payload that needs to make it back to Lua, and the amount of work it then has to do when checking whether or not the entities that were hit by the shapecast can take damage or have some other effect applied to them.

Conclusion

No navmeshes happened in the past month, but the new features are important additions nonetheless.

There is a ton of work left to make the editor side of the new features be as user-friendly as possible. Better visualization for the colliders, ensuring that things like invalid scales originating from the editor don't make it all the way to Jolt, assigning colors to each physics layer, so colliders in different layers are colored differently, an UI letting you decide which layers get rendered at all, and lots more that I probably haven't discovered yet.

The next major physics feature that will be required someday is support for trigger-type objects (those that only raise events when they collide with something, and are otherwise pass-through).

I'll wait until I have to implement a gameplay feature that needs it, it's always more fun that way.

Now back to navmeshes... surely.

For any questions or feedback, find me on Bluesky

Firefly in the Dusk🌙

DuskEngine Devlog 0 - Quick Overview

2025-10-17T00:00:00Z

DuskEngine is a game engine that I'm writing for myself. I started development on it about three years ago. I am also currently designing a game that will use it, but I try to have a more generic approach wherever possible; at the end of the day I wouldn't mind using this engine for more than one game.

I post about it a lot on my bsky so head on there to see more videos and screenshots and such.

The development scene in DuskEngine at the time of writing

Technical details

I use C++ and the bulk of development happens on Windows. The renderer there uses OpenGL. MacOS is also supported (I ensure the project builds and runs on a weekly basis), but the Metal renderer is very far behind in terms of features (due to a lack of time on my part). But it does have raytraced shadows, so there's that 😝

The engine compiled and ran on Linux a few months ago but unlike MacOS, I don't make Linux builds regularly, but would like to change this eventually.

I normally think of DuskEngine as "the editor" together with "the engine". The editor, when you make a build that includes it, kinda sits on top of the engine and represents all the editor tools that you use to make your game. The engine is the thing you turn on which then does its thing.

The editor uses Dear ImGui for the interface.

Both the editor and the engine (i.e. play mode) use Lua for scripting purposes. I use LuaJIT and sol2.

You can even write entire editor windows in Lua, as can be seen here.

Whirlwind tour of some of the other larger deps:

I use Jolt for physics.

And ~~SoLoud~~ FMOD for audio, see here.

Assimp for mesh loading.

Cereal for binary serialization. There is an asset import (and reimport) functionality, which takes the raw asset files (such as .pngs, or .gltf) and turns them into engine-specific data. Cereal is used to serialize and deserialize this data.

SDL2 for windowing and input.

GLM for math.

boost for json parsing and writing, uuid generation and others.

Tracy for profiling.

ImGuizmo for the editor gizmos.

BTW, unlike the editor UIs which use ImGui, the gameplay UIs use a custom implementation. Gameplay UIs are assets and there's an editor for them too:

There is a lot of work left to do for the UI side of things, besides the layout, the renderer also needs improvements.

It is somewhat similar to the one in Unity, using pivot points, anchoring, margins and so on.

Unlike Unity, the UIs are not objects in the scene. You can have as many UIs as you want, even if they're not rendered by a camera (you might render them to textures). The scripts that manage those UIs choose when and how they update.

I will likely refer to Unity again in future articles, because it's the engine I have the most experience with (I've been using it for about 10 years at the time of starting work on DuskEngine, I don't really use it anymore), so my idea of what an engine should be like is at least in some amount, inspired by it.

For a fun UI system example, see this mobile phone UI which gets rendered to a texture that then gets applied to the phone screen. The mobile phone controller script uses raycasting from the mouse cursor position, by converting the ray hit point from the phone screen's collider's coordinates into UI (essentially UV) coordinates. Finally, it triggers an update with the generated inputs to simulate the touchscreen.

What I'm actively working on right now

I want to implement some fancier NPC behaviors and so I've added navmesh support via the Recast library. I'm currently making it work all the way from the asset side to gameplay scripting.

Tech goals and questions for the near(ish) future

Occlusion culling needs implementing. Especially important as I've started adding more and more buildings to the scenes.

More renderer features with better visuals are needed.

I really need to set up some kind of build system, I use a Visual Studio solution and an Xcode project for Windows and Mac development, and whenever I change something in one I need to also change in the other. The versions of some of the dependencies are also different between the two platforms, which will eventually need to be fixed. Setting up something like CMake will allow me to streamline this process and also start making Linux builds periodically, but I'm so not looking forward to learning CMake's scripting language and since this doesn't really cause much pain during day to day development, I'm postponing it as much as possible 😭

Compile times are slow 😞 I am a bit conflicted on how high a priority this should have, because my Mac compiles lightning fast compared to my old Windows laptop, but there is plenty of room for optimizing the compile times. I've done a few such optimization passes in the past, with good results. I'm not a fan of all the hacks and workarounds C++ programmers seem to have to do in order to make up for this antiquated build system. I haven't taken a look at module support in a while, but I doubt Apple has it yet so...

I need to set up an experiment to see what it'd be like for two or more developers to try to work on the same DuskEngine project, through something like branches and PRs in Git. Everything is text (JSON), but I'm not yet sure how smooth it would be. I know collaboration can be a major PITA, and would like to run into issues and fix them ASAP.

Another feature is the asset store functionality, which at the moment is more or less a stub, but on which I'd like to continue work sometime in the near future. This is so that the issue that some assets can come from a server somewhere, and need to support updating when new versions get released, is tackled as soon as possible.

On a somewhat tangential topic, I'm not yet sure how I'm going to handle having the games download assets while running, like how mobile games do it for example.

Also, two things I'd like to add in the future is support for web and at least one mobile platform (probably iOS because I already have the Metal renderer). Web is the most important because it'd make sharing builds with the world much easier. Mobile is so I get to see what packaging a game would work like under the constraints of mobile platforms.

Plus a bunch more features that I'm forgetting about 😄

For any questions or feedback, find me on Bluesky

Firefly in the Dusk🌙

My first post

2025-06-13T00:00:00Z

Hello!

This is the first post here, just to test the functionality. Stay tuned for actual gamedev articles.

For any questions or feedback, find me on Bluesky

Firefly in the Dusk🌙