What happens when Visual Studio throws a compiler error, stating that it can't find a specific header file that's in the same directory as all the other files? And that the solution explorer can open just fine? The answer: Create a new project and start porting. And while I'm at it, I might as well make a few changes to existing systems, such as how the viewport UI is rendered.
As part of my efforts to make my own game engine, I've been making a ton of libraries that I want to use in all of my projects (from my game engine and games to Sandbox 2.0). However, while my game engine will need all the features of the GUI library, Sandbox 2.0 does not. For the most part, Sandbox 2.0 uses the MFC's GUI, but that's only for elements outside of the viewport. For elements within the viewport, I need my own GUI system. And while I have been using the monolithic GUI system that I've been working on for my game engine, there's really no need for that system within Sandbox 2.0.
My game engine, for example, needs buttons for navigating through different screens and for other things, sliders for adjusting certain types of settings, toggles for other types of settings, drop down menus, images for both element backgrounds and for thumbnails, text elements for basically everything, text edit fields, and many other types of elements to make a fully-function GUI through which the user can interact with my games. But Sandbox 2.0 only needs text elements and a solid background behind each text element to make sure that the text is always clearly visible. All other elements will be handled by MFC.
For this reason, I've decided to not to use my GUI library and instead create a simplified version specifically for Sandbox 2.0. And not just for Sandbox 2.0. The way I figure, I'm going to need to make multiple types of editors for all of the games I want to develop. And since these editors will all be using MFC or similar framework for the GUI outside of the viewports, the only thing that these editors will need is the simplified GUI library for rendering text elements within the viewport itself.
Why do I need to implement a GUI system specifically for the editor's viewports if the framework I'm using has its own GUI system? There are two main reasons: First, because the viewport uses a 3D graphics API (eg: DirectX 11), making a GUI system that works within that same graphics API means I have better control over how the GUI elements look. Secondly, if I were to use the frameworks' GUI system, even if I could make it look the same, would cause the viewport window not to receive messages if the mouse were to move over these text elements that are within the viewport. That's simply unacceptable. By having the viewport have its own, independent GUI system, I guarantee that the viewport will always receive mouse input messages.
The popup menus that appear will not be using the GUI system, because when the menu is opened, it should receive the messages instead. And sometimes, the menu can leave the boundaries of the viewport. That would have to be prevented if the menu used my own GUI system. It's just easier to let Windows do all that work.
Something else to note about my editor's new GUI system is that the text element only has to display one line of text per element. And the background that keeps the text visible does not have to be its own element type. This will simplify the GUI system further and make updating the text faster. It does mean that the text element has to render 2 objects though, but even that will still be faster than rendering two separate GUI elements per text element.
Also, the GUI system is in a separate project from Sandbox 2.0. Since I'm going to be using the same system for multiple projects, I might as well have it as its own project and have all of the editors reference it.
No comments:
Post a Comment