<\/td><\/tr>Now, I’m always banging on about how libraries should be as focused and unencumbered as possible, how you shouldn’t need to go on a multi-stage fetch quest to get the thing to compile like you were trying to assemble the pieces of the Tri-Force or something. The problem is, there is pretty much no way around this. Interfaces need to use fonts, and fonts are fiendishly complex beasts. Interfaces need to render stuff, and rendering is complicated. They need to process keyboard and mouse input, and those are complicated. (It seems simple, but tracking keyboards and mouse wheels and all the different things that can happen with the CTRL, ALT, and NUMPAD… it gets very hairy.) That’s a lot of things for one library to do, on top of running a window system with buttons and scrollbars and the ability to tab between interface elements and all of the other tiny details that we all take for granted.<\/p>\n
Still, the inability to adjust options is really killing my productivity. So let’s see what we can find.<\/p>\n
Let’s see. We need an interface system that works with OpenGL. We’ve got Crazy Eddie’s GUI system<\/a>, FLTK<\/a>, GLAM<\/a>, GLUI<\/a>, GL Gooey<\/a>, LibUFO<\/a>, Qt<\/a>, Turska<\/a>, wxWidgets<\/a>… and probably others.<\/p>\n Wow. That is a very daunting list. Some of these libraries won’t have the functionality I need. Some will, but will have horrible dependency issues (some may even encapsulate others, or be forks of other items in the list, I don’t know yet) that will make them prohibitively difficult to use. Others will have horrible C++ interfaces that make a cluttered mess of your code. Some will have the functionality I need, but will lack the visual customization I need. (I know a few of these are designed to create standard “windows” style interfaces, which would look just awful floating atop my Seussian fantasy world.) Some might have all of the above, but be tied to a particular platform. Or lack proper documentation. Or turn out to be long-abandoned projects that no longer work due to shifting technology.<\/p>\n I could easily burn a couple of days downloading each and every library, getting it to (hopefully) compile, testing it out, evaluating the interface, the looks, reviewing the documentation, and making sure it actually has all the features it claims to have. (I don’t want to install the thing into my project and three days later discover that something fundamental like “text input boxes” is still on the to-do list.) This promises to be a massive investment of time. The truth is, I’m not ready to make this kind of commitment. Really. It’s not you, it’s me. I just can’t afford to be tied down at this point in the development cycle. <\/p>\n I began this project as a tech demo, that could<\/em> become a game. But the tech demo comes first. And adding a all-singing, all-dancing, multi-window interface falls way, way outside of that scope. <\/p>\n Thinking about this more, what I really need is a “Quake-style” console. If you ever hit the tilde key in Quake, you probably saw the text window that opens up. That window lets you enter commands, change variables, and generally control the application without needing menus and scroll boxes and the like. This is exactly the reason console windows exist: For the proof-of-concept \/ prototyping stage of a project. <\/p>\n It works. It works beautifully. It works seamlessly. It dropped directly into my project with no additional dependencies. It displays text, but I have no idea how. I don’t see a bitmap among its resources and it doesn’t do any font loading. It just magically makes text. I suppose I could look at the source, but so far there’s been no reason to do so. I was able to add it to my project in, I kid you not, five lines of code. I tell it when to open and close. I tell it when to draw. I feed it keypresses. That’s it. Done. I don’t even need to initialize it. <\/p>\n Even better, it comes with a bunch of other features:<\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n\n
<\/td><\/tr><\/table><\/p>\n