Hi everyone. Welcome back to the Triworld devlog.

Editor Done

I’m mostly done working on the Editor. Here are a few models I made with it:

Triwold daisies Triwold mushroom Triwold head

My artistic skills need some work, but at least the Editor works perfectly.

I’m a bit behind schedule because I tried to write my own Immediate Mode UI library. This is how the Editor looked:

Triwold Editor with Custom UI

It was an interesting learning experience, but making a fully featured UI library is a lot of work. So, I decided to ditch the custom UI and use Dear ImGui instead. This allowed me to focus more on Editor features.

I’ve added import/export support for MagicaVoxel’s VOX files:

VOX Knight

And drag-and-drop to open files:

Triwold drag and drop

World Generation Tests

I’ve also been busy working on world generation. Here are some early tests:

Triwold World Gen 1 Triwold World Gen 2 Triwold World Gen 3

It still needs a lot of work because I haven’t yet captured the aesthetic I want.

Linux Support

A friend of mine wanted to try the Editor, but unfortunately, he is on Linux. So, being the good friend that I am, I rewrote the entire Win32 platform layer to add support for Linux. It was relatively easy, thanks to SDL3. Now both the Editor and Game run on Windows and Linux. I think this choice will pay off in the long run. SDL3 is a very minimalist dependency and runs on many platforms (at least the ones I may target one day).

Here’s the Editor running on Ubuntu:

Triwold Editor on Ubuntu

Tech Stuff - Dear ImGui vs Custom UI

If you’re interested in writing your own Immediate Mode UI library, I highly recommend Ryan Fleury’s Substack: UI, Part 1: The Interaction Medium. His post on Arenas is also a must-read, in my opinion: Untangling Lifetimes: The Arena Allocator.

Bear in mind that writing a fully featured UI library from scratch is a lot of work. The core library may be a few thousand lines of code, but the complex parts are the widgets, font rendering (for various languages), and interactions with the mouse and keyboard (and maybe controllers). This is ultimately why I ditched my custom implementation and switched back to Dear ImGui. Being a solo developer, I must choose carefully where to focus my time and balance learning with making progress.

Dear ImGui has improved a lot since the last time I used it. The Vulkan backend is more mature and easier to integrate, and customizing the look for my needs was easier than expected.

These are some of the Editor panels:

Triwold Editor Inspector Triwold Editor Console Triwold Editor Memory Profiler

The stack now looks like this:

  • Orthodox C++ with Vulkan
  • Dear ImGui (with IconFontCppHeaders)
  • Volk
  • SPIRV-Reflect
  • glm Switched to my own math library
  • nanosvg
  • stb (image, image_write, sprintf)
  • catch2
  • SDL3
  • No STL

The tools I’m using are:

  • Editor: VSCode with clangd
  • Compiler: MSVC on Windows, Clang on Linux (both with CMake, but more on this later)
  • Profiler: Tracy
  • Debugger: RemedyBG
  • Graphics Debugger: Nvidia Nsight and RenderDoc
  • Static Analyzer: PVS-Studio

I’m trying to use CMake instead of my build.bat with a unity build, but so far the experience hasn’t been great for a few reasons:

  • Compilation times: I switched from a unity build to building separate .cpp files, and a full recompilation went from 2 seconds to almost 30. An incremental compilation can take between 2s and 10s. This is clearly not a problem with CMake, but it baffles me that this is the standard method in the C++ community.
  • Corrupt build: A few times, the debugger behaved weirdly, and the problem got fixed when I deleted the build directory and relaunched CMake. I don’t have an explanation, but it never happened with my unity build.
  • Lackluster documentation: The documentation you find online for CMake seems outdated (even if just a few years old) and assumes you already know some CMake terminology or are willing to sink hours into learning it.
  • Leaky abstraction: My project is quite small, yet I already had to pollute the CMakeLists.txt with compiler/platform-specific rules. Maybe there’s a better alternative with presets, but see point 3.

Maybe I’m the crazy one, but I don’t really see the reason for the added complexity. For the foreseeable future, I will keep both the CMake build and the unity build using a build.bat and build.sh.

Stay tuned.

Alex