I love Dear ImGui. I use it every day and it's probably the most important contribution to independent development in the last decade. So when it came time to start thinking about making in-game UI, why not just create a similar immediate-mode system so that I can just make all my EGA RPG text and buttons and interactions work with literally the same API I use for my tools.

---

The code for the popup dialog there is

   egaui::setNextWindowPos({ 380, 32 });
   egaui::setNextWindowSize({ 300, 100 });
   if (egaui::begin("test 2!")) {

      egaui::text("Testing some UI");

      egaui::indent();

      egaui::beginGroup();
         egaui::alignTextToFramePadding();
         egaui::text("A button");
         egaui::alignTextToFramePadding();
         egaui::text("Another button");
      egaui::endGroup();

      egaui::sameLine();

      egaui::beginGroup();
         egaui::button("Btn 1");
         egaui::button("Btn 2");
      egaui::endGroup();
      
      egaui::unindent();

      egaui::setCursorPosX(egaui::getContentRegionMax().x - egaui::calcTextSize("Right Aligned").x);
      egaui::alignTextToFramePadding();
      egaui::text("Right Aligned");
   }
   egaui::end();

What's great about this, is this API is simple enough that later down the road when I start thinking of LUA/Scripting integration, creating bindings to enable scripts to define arbitrary UI becomes trivial. Custom menus and dialog trees and everything will be able to developed in the same asset system everything else uses.

Of course the real fun of all of this is that this API exists running inside a game instance that is being rendered to a full ImGui window:

edit: added a better looking window frame :3

#gamedev #chron4 #imgui

| 🌐 | 🙋‍ | @britown@blog.brianna.town

I've always had this pipe dream of being able to live-edit all assets in a game project while the game is running and I'm feeling really strong about the progress of this newest project!

---

Most/all of my personal side-project revolve around C/C++ desktop apps with homespun engines. It's usually as much a journeyman effort for learning more CS as it is a desire to make a game. A big part of solving the issue of finishing a game has to do with having good architecture with a good assets pipeline.

In this example we have:

• The assets data-catalog is on the top left
• A running game instance in the top right (can have multiple running in windows independently in the same exe)
• A tile schema editor for map tiles in the bottom left
• A homemade pixel image editor in the bottom right.

Any pixel edits to the graphics in the editor live-update anywhere they are used (in this case both the running game and the schema editor) giving you redundancy to test your edits. It also has perfect referential integrity so you never have to worry about your game crashing when an assert comes up missing.

I will have to come up with some thoughtful posts digging into the how's and why's of all of this but the main concepts at play here are:

• “C-Style” C++
• Generated reflection code from struct definitions
• Generic recursive file format
• Live++
• Dear ImGui

#gamedev #chron4 #cpp #imgui

| 🌐 | 🙋‍ | @britown@blog.brianna.town