The terrain streaming / planet rendering stuff was the last of the feature creep. That finishes out the features I have planned for the first release of the new engine. My approach for development has been to go very broad so I could get a handle on how all the features work together, solve the hard problems, and then fill in the details when convenient.

The hard problems are all solved so now it's just a matter of finishing things, Consequently, I don't think my blogs are going to make any more groundbreaking feature announcements, but rather are going to show steady improvement of each subsystem as we progress towards a finished product.

The GUI is something I wanted to spend some more cycles on. The initial release of the new engine will be a pure programming SDK with GUI support, but the GUI I am implementing is also going to be the basis of the new editor, when that time comes. I decided that using Lua scripts to control widgets was a bad idea because when operating at-scale I think this will cause some small slowdown in the UI. My goals for the new editor are for it to load fast and be very snappy and responsive, and that is my highest priority. It is nice to have overarching design goals because then you know what you must do.

I've started the process of converting our Lua widget scripts into C++ code. The API now has functions like CreatePanel(), CreateButton(), etc. and is much more formalized than the flexible-but-open-ended GUI system in Leadwerks 4. For customization, I am implementing a color system. We have a bunch of color constants like this:

    enum WidgetColor
    {
        WIDGET_COLOR_BACKGROUND,
        WIDGET_COLOR_BORDER,
        WIDGET_COLOR_FOREGROUND,
        WIDGET_COLOR_SELECTION,
        WIDGET_COLOR_HIGHLIGHT,
        WIDGET_COLOR_AUX0,
        WIDGET_COLOR_AUX1,
        WIDGET_COLOR_AUX2,
        WIDGET_COLOR_AUX3,
    };

There is a Widget::SetColor() command that lets you set any of the above values. Now, this is not a complete set of colors. The GUI system uses a lot more colors than that. But these colors are generated by multiplying the defined color by some value to make it a little darker or a little lighter.

This means I am making a decision to reduce the flexibility of the system in favor of more formalized feature support, better documentation, and better performance.

I think we will be able to load a color scheme from a JSON file and that will allow enough customization that most things people want to do will be possible. For custom widget behavior, I think either an actor or a DLL plugin could be used. There are enough options for future extensibility that I feel like we will be okay deferring that decision for now, and I am not coding myself into a corner.

Here's a shot of the current state of things:

I probably have enough GUI code ahead of me I could just go silent for a month and stay busy with this. I don't really want to think about that for the rest of today. Goodnight.