Development Blog

Yes, and functions like GUI->DrawText() would also work on all three?

What would really be the difference between window/context in this case? It seems both would handle input/events automatically and you still could make a 3D application with the context right?

I talked about this in the hangout but I guess I haven't actually written about it. I'm refactoring the window class to add direct drawing to windows without a 3D context, using the actual OS commands the native UI is drawn with. This avoids the little niggles that 2D-in-3D GUIs have, like FRAPS displaying the framerate on the window, the UI flashing on the first time it is rendered, little sections of corrupted graphics, dependence on a 3D card and drivers, etc.

 

The OS-level drawing commands also provide faster and higher quality text rendering, and built in features like word wrapping (although I had to write this custom for Linux).

 

This isn't really meant as a feature for you to use, but if you are writing any custom tools this would give you a consistent GUI on Windows, Mac, and Linux that is simple to use, something the entire open source community has failed to provide.

 

I want a custom UI for Leadwerks Editor, and the engine needs a GUI system, so this is a way of killing two birds at once, rather than developing two systems side-by-side, or trying to render the Leadwerks Editor interface with a 3D context.

That's what I was thinking you meant but my first thought was "Wow, that's a big goal". So basically you are replacing BMax with your own Lua/C++ based crossplatform GUI library and having the structure just flow into the GUI stuff for games (on the context) as well. If you can pull it off you could sell it separately probably as a crossplatform GUI library that's easy to use is always welcomed.

Plus a MaxGUI wrapper so I can just swap the BMX module out and the editor will recompile and work with no code changes.