Tag Archives: GUI

GUI, Part III

Scrollable windows! That's the big accomplishment for the past two days.  I certainly wasn't planning on implementing them when I started, but it was just too tempting.  Not surprisingly, it took a lot more work to implement scrollable windows than any other GUI component so far.  Still, they're done now, and I'm happy that I put in the time.  They're going to be absolutely crucial for complex games.

Oh, and those are checkboxes.  They're not too interesting - only took about 5 minutes to implement, since they're really just handicapped progress bars (at least, that's how I see them).

GUI, Part II

Work on the GUI system is coming along nicely.  Edits and windows have both improved substantially.  Progress bars and sliders have been added to the mix.

Truth: the only real reason for this post is to show off my sliders, since I'm super-proud of having finally made a half-decent UI :D

GUI

And now, for something totally different...naturally, a terrain engine can't hold one's attention forever.  I've taken a temporary break to revisit the GUI engine that I started some time ago and left in an embarrassing state.  I'd like to start making some stupid, simple game demos, just to have some fun with the engine...but I'd certainly need a tight GUI system for such a game.

So far, I've overhauled fonts, labels, edits, and buttons, and added basic windows and windowing.  Everything is shaping up nicely, or, at least, much better than last time. I ended up using a fairly interesting design pattern for the GUI elements, since I wanted to modularize functionality as much as possible without losing efficiency. To this end, I went with a templatized decorator pattern. As in, the c++ decorator pattern, but with templates, so that all code is generated at compile-time and any given GUI object (in theory) becomes the sum of all of its functional parts without the overhead of dynamic linking.

Looking Back, Looking Forward

After finishing some more serious work on the new interface today, I took a moment to appreciate the distance that the program has come over such a short period of time.  In my notes I have a screenshot of the main interface from April.  At the time, it was cutting-edge.  The new treeview made organizing the composition a lot easier, and the cute little banner up to gave the program some personality.

And now I look at what I've designed over the past week.  It's come a long way.  It's come from a shoddy, single-button proof-of-concept, to a complicated but functional panel, to a more organized treeview skeleton, and finally, to a user-friendly and ultra-sleek tile palette.  Visual progress is the easiest to see, which is why it makes me happy to know how much mGen has evolved over time, even if the inner workings aren't leaps and bounds ahead of those that were in place months ago.

If nothing else, I have succeeded in creating a very unique and functional platform for algorithmic composition.  That, in itself, is a success.  Whether or not I will be able to furnish this platform with the functional modules it will require to make amazing music, I do not know.  But I know that I've done something.  I've contributed.  And that's what I set out to do.

On a side note, I had a strange moment today when the new interface gave its first output (yes, the new renderer is already working...it's true, I've come a long way as a programmer - I did indeed make it in about 1/3 the amount of code as the last renderer).  It was a simple test with only Easy Contoured Structure, ProgLib, GGrewve, and ChillZone pianist loaded.  Everything seemed to be going fine.  But then ChillZone freaked out.  It started doing crazy inversions and removing and adding notes somewhat randomly.  Weirdest of all though, was that these notes were all perfectly acceptable.  It was still playing in the key...but it was doing something I've never seen before.  Exceptionally odd.  The code hasn't been modified in over a month, as indicated by the timestamp!  So what on earth is causing this "ghost-in-the-machine?"  It's a pretty cool bug, I admit (if a little creepy).  But I'll get to the bottom of it.

Almost Finished with Primer

I'm continuing work on the new interface and progress is being made very rapidly.  I've almost finished the frontend.  All I have left to do is apply some cosmetics to the render button and then add some menus for render settings.  For the most part, however, the important work is finish.  Module loading and changing works perfectly.

I'll probably tackle the data handling soon.  Maybe tomorrow if I work fast.  I've been working very fast lately though, and I'll have to keep up this pace if I hope to make my next deadline - 23,000 lines by the 15th.  Looking at this now I know it's not possible.  That's simply too steep of an increase from the last deadline (17,000 on the 1st, which equates to 400 lines per day for fifteen days straight).  Regardless, I can try to get as close as possible to this mark.

Sleeker, Faster, Prettier

The emerging interface is both proof that hard work can accomplish anything, as well as hope for those like me that thought interfaces can't be designed without artistic talent.  With enough fooling around in photoshop and the likes, I managed to produce an interface that, to my standards, is extremely slick.

I hand-coded all the controls, so you'll find no standard buttons, listboxes, etc. in the new interface.  Everything is custom.  And the work paid off.  It looks great.

Not only does the interface look great, it also works great.  It will be a very powerful and streamlined interface when I finish it.  I've already finished the plugin loading functions and the structure & progression tiles are already fully-functioning.  Unlike in the last GUI, where the user had to double-click the correct treeview entry, select a text-only plugin name from an ugly listbox, then click an OK button, the new interface demands only two clicks to load a plugin: one on the tile into which the plugin will be loaded, and the second to choose the plugin.  Furthermore, plugins are displayed as tiles instead of text, so finding the right one among many is as easy as identifying the correct icon.  It's way faster (not to mention way more fun) to load and configure plugins now.

As soon as I finish the frontend, which will probably be a few more days, I'll have to start grinding out the backend.  I feel like the last interface's rendering functions were bloated, to say the least.  I hope to be able to do it all over again in less than half the code.  I think that's pretty reasonable given how much I've improved as a programmer since the time the original render code was written (seventeen thousand lines ago).

Things are definitely looking up for mGen's aesthetics...but the real question is: will these new aesthetics inspire more creative advances?  Or will mGen just be a good-looking failure?  I guess I'll have to keep pressing onward to find out.

Tweaking the GUI

I made the GUI look a little prettier today. I am still withholding screenshots from the blog, however, because I do not want it to be seen until it is ready.

I am also working on filling up the main panels of the program, since the border regions are populated with functional tools, but the center area is completely blank. I'm not sure what to put there.

Renovations

I've completely deconstructed the program's main GUI over the past few days and am now in the process of redesigning it to be sleeker, more efficient, and more powerful all at the same time. It's starting to actually look like a real piece of software now. One of the problems with algorithmic composition is that it's so darn complicated. If I'm ever to get this thing going mainstream, users will need the interface to be intuitive and easy to use.