The widgets are now really revamped. I went full out on the text entry widget and allowed for scrolling through the text. It's still not multi-line, but it's leaps and bounds more useful than it was before. Editing text in the entry area is very nice now, with full color customization, text customization, etc.

With the text area out of the way, it really was time to finally implement a usable file browser that looked decent. Since the file browser builds upon the listbox, buttons, and text entry it wasn't too complicated to simply hook everything up and get it working correctly. Most of the work came in the form of layout issues. I really wanted everything to line up properly, and be enclosed within a single box that is customizable (in terms of color). This is a little trick to do without some sort of auto layout manager. It's something I'm considering for the future, but coding everything specifically for the file browser was the way to go "for now".

Of course, after the file browser there was still a menu system that needed to be done. This was something that had no foundation at all, and was basically a from-scratch effort. Implement it, I did, though. A dropdown menu system is now in place that supports submenuing (infinite), as well as full customization of color and moderate customization of text. It uses a simple callback system for selectable items in the menu. This is going to make revamping the editor in my game so much easier.



With all of these GUI elements at hand I can stop using special magical keyboard shortcuts in the editor and create a usable UI that is, at least, a bit more intuitive.

I'm not sure why I took so long to do it, but I finally implemented a basic version of all the power-ups the player will receive in the game. I've had them listed out for quite a while, but always put off throwing them into the code base. I have a feeling it's because I didn't have either art, or a proper way to test them out. Needless to say, I bit the bullet and just implemented basic versions of everything. It's coming together quite nicely, but there is still a bit of work to do. In trying to test out some of the new functionality I had to play around in the in-game editor quite a bit. It was obvious while using it that the scheme I have currently isn't going to scale to a full featured and easy to use editor. Almost every action consists of having to utilize special keyboard shortcuts. I want to get away from this and start to use more mouse based operations, as well as have a proper GUI.

I've revisited a lot of the SuperMissile code. Most of the widget functionality has been rafactored and relies less on strange quirks to operate correctly. Generic buttons and listboxes have been fine-tuned. I'm still dealing with some problems with text entry. Prior to my most recent changes, it was impossible to move the cursor back and forth through already entered text. The user would have to delete anything they entered if they wished to change a character. This functionality is now available, but there is some tweaking to do. For instance, if you scroll back through large amounts of text, the text isn't actually clipped, so it will overflow the bounds of the text area. On top of that, it only allows for single line text entry. I'm not sure if I want to go all out and allow multi-line input or not.

After that, it's a matter of beefing up the file browser. There are lots of issues there, but many of those are resolved by fixing the text entry and listbox widgets (since it uses those directly). Once that's customizable the next step is to build a menu system. With menus I could really overhaul the entire editor for the game--making it much more accessible than it is now.

Apparently my naming scheme merge didn't work as well as I had hoped. For once, I thought SVN merging was easy; but I was wrong. In the end I fixed up the problems I was having. Thankfully I hadn't done a lot of work on the codebase between the merge back into trunk and finding out that a bunch of the files in .svn got mangled during the merge process (nice!).

Other than SCM woes, I added a rudimentary implementation of the player's ability to carry other objects in the game world. Naturally, this will extend to other object types (think NPCs carrying around other NPCs), but for now it's a step in the right direction. It's incredibly fun picking up NPCs and moving them around with the player. It needs some work in order to look like the player is actually carrying the thing he is carrying.

Each time I add in something new like this I can't help but think about all the artwork that's going to need to be done to make it look "just right." I've got my work cut out for me (or someone else!)

The rename conversion is complete, less any tiny little things I may have missed. This includes all filename conversions, as well as certain data files, data file contents, and broken game data that could not be salvaged (test maps saved with old formats, etc). It took a few days, but it's just about there and it feels pretty good.

Also fixed up a bunch of little bugs that I hadn't even noticed existed, which is always nice. It's classic when you're modifying objects in an editor and are able to set attributes that should not be settable. It's even cooler when it results in crazy things happening, like objects simply floating away into the ether instead of staying put. I got a laugh out of that one.

I'm not sure exactly what's next on the list. I have a list of a few things that definitely need to be looked into; some of them much more tedious than others. In the long run, what I really want is some sort of assets I can use to help me get started on pushing through AI for the NPCs in the game world.

A little bit of history to my platformer...

It started out as an Allegro-based game. During development I ran into some nasty shearing problems which simply had to be dealt with. The solution was to get some hardware acceleration going on for the Mac side of things. This required either moving to AllegroGL, or some other OpenGL backed solution. In the end, I chose SDL for one reason or another. It was time to grow out of the old Allegro roots and move onto something new. Ironically, Allegro5 is growing out of its old roots, too. Unfortunately, it's not ready yet -- so I had to run with something that is. Thus, I made the switch to SDL+OpenGL. It's been working perfectly without any major drawbacks thus-far. I had to write a few methods that were absent from what I had available in Allegro, but it wasn't really much sweat off my back.

Long story short, the library I developed to wrap SDL, OpenGL, and a few other libraries used a different coding style than Allegro does. The problem now was that I had a mixing of camelCase and underbar_style. Bad news. I decided it was finally time to upgrade the game's code to use the new camel case style. It's taken a while, but it's almost there. The entire codebase has undergone a complete conversion, including renaming of files and elimination of almost all of the underbar style naming scheme.

It looks like all that is left is to rename a slew of the data files I have created, and some of their contents. Shouldn't be too long before I start to either implement some new stuff, or take that bold step into generating some placeholder artwork (this always kills me!).