It’s been a little while since my last update on the Kaban Engine refactor, and I’ve been busy wrestling with input handling, integrating Nuklear more deeply into my codebase, and sorting out some UI quirks. Progress is steady, and I’m starting to see the light at the end of the tunnel—or at least a less foggy path forward. Here’s what I’ve been up to since last time!


Input Handling: Borrowing from GLFW

After ditching GLFW for window management (see my last post for that saga), I still found its input handling code pretty solid. So, I peeked under the hood, grabbed some of its input-fetching logic, and ported it into my engine’s platform layer. Nuklear needs specific inputs—keyboard, mouse, the usual suspects—and GLFW’s approach fit the bill. Porting it was painless; I just tweaked a few things, wrote some wrapper functions, and it was good to go.

I decided to keep my existing input handling as-is instead of ripping it out. No point in reinventing the wheel or re-fetching inputs from Nuklear’s nk_context when I can let Nuklear do its thing and handle my game inputs separately. Clean, simple, done.


Nuklear Integration: Platform Layer FTW

Next up was figuring out how to integrate Nuklear into the engine properly. I had two options:

  1. Split the Nuklear implementation between the platform layer (input/rendering) and the game/engine layer (UI logic).
  2. Keep everything in the platform layer and pass function pointers to the game layer for UI calls.

I went with option two. It’s cleaner—input fetching and rendering stay in one place, and I don’t have to mess with re-fetching inputs in the game layer just to keep Nuklear happy. Here’s how it works now:

  • On startup, I initialize a stack of function pointers for all the Nuklear UI functions the game layer needs.
  • Then, I set up a platform-specific structure (Windows, in my case) that holds inputs, rendering info, and the Nuklear context, passing it to the engine layer.
  • In the main loop, it’s input fetching first, then the engine/game does its thing, and finally rendering.

For rendering, I initially thought about writing custom functions for Nuklear’s shapes—lines, triangles, etc.—but then I spotted a handy OpenGL-based rendering function in Nuklear’s demo code. It takes arrays of vertices prepped by Nuklear’s built-in system and draws them. I ported that function, slotted it right after my engine’s rendering call, and boom—UI on top, no sorting headaches. Most folks want UI on top anyway, so it’s a win.


Debug UI and Resolution Hiccups

With Nuklear humming along, I created a second context for my debug system and rewrote all the debug UI to use Nuklear. It took a few hours, but now the debug tools are back online, looking sharper than ever.

Then I hit a snag: screen resolution. I wanted the UI to look consistent across displays, but different resolutions were throwing things off. For now, I’ve locked the UI to a fixed 1280x720 resolution. Why that size? On smaller, non-HD screens (like my laptop’s), a bigger resolution shrinks UI elements too much. The engine’s rendering pipeline—big shoutout to Casey Muratori’s Handmade Hero series—already handles resolution-independent projection, so the game visuals scale fine. The UI fix is a bit of a hack, but it works for now. Smarter solutions can wait.

Before and After: The UI Glow-Up

Rewriting the UI with Nuklear wasn’t just a technical win—it’s a visual one too. I figured I’d share a quick before-and-after to show the difference. Here’s what the debug UI looked like pre-Nuklear:

The old debug UI—functional, but a bit of a mess.

The old debug UI—functional, but a bit of a mess.

Cleaner, crisper, and way more usable. Nuklear’s doing work!

Cleaner, crisper, and way more usable. Nuklear’s doing work!

The old setup got the job done, but it was clunky and rough around the edges. Nuklear’s immediate-mode approach makes it so much easier to tweak and maintain, and it looks a heck of a lot better too. Progress!

Current Work: Asset Editor UI

As of today (April 1, 2025—yep, still chugging along!), I’m rebuilding the editor UI with Nuklear. Right now, I’m focused on the asset building system, which lets me add or remove assets from the game’s asset file. It’s coming together nicely, and seeing the editor take shape is pretty satisfying.

Next Steps: Map Editor and Beyond

Once the asset editor UI is done, I’m moving on to the map editor—another Nuklear overhaul. After that, I can finally tackle navigation meshes and player movement, which I’ve been itching to revisit since my first “demo” way back when. Step by step, the Kaban Engine is turning into something real.

Wrap-Up

That’s the latest from my corner of the coding world! Input handling’s sorted, Nuklear’s playing nice, and the editor’s getting a facelift. It’s still a chaotic little beast, but it’s my chaotic little beast, and I’m loving the ride. Got thoughts on resolution handling or editor workflows? Drop a comment—I’d love to hear your take.