The new scrolling text bubbles are, for the most part, in place. Text bubbles are essentially containers for text with a graphical border which can display the text a single character at a time, looking like a classic speech display in various types of games. Currently the system allows for different sized margins across the top, bottom, left, and right portions of the background imaging for the bubble itself. These values need to be passed in along with the texture information, so text bubble texture + margin information is a good candidate for stuffing into a plist. If I'm going to be dumping stuff to a plist, I might as well have a visual editor for it! Some may say this is overkill, but I do prefer to be able to look at the margin sizes visually and know they will work in the application without having to keep moving back and forth between hand editing a file and testing it. Also, creating an editor will (if all goes well and I don't introduce anomalies into my code, of course) produce consistent results. Besides, the code that runs Beeboxer can be, for the most part, duplicated and used to perform the operations I need in order to generate margin values for a text bubble texture.

On aspect of the text bubbles that is unfinished is escape sequencing. I would like to have the ability to change text color on the fly, as well as the speed of text and optionally all sorts of other neat effects. This is currently an issue however, as I'm displaying text from the bubble by passing the substring of the entire string to be printed out. why is this an issue? First of all, if I handle the escape characters at the low level printing stage, passing a string without the complete escape sequence intact will print portions of the escape sequence before it realizes that there is a complete escape sequence to be printed. On the flipside, if I handle escape sequences before moving to the printing routing, I am still passing the entire string to be printed, and therefore, while I have done what the escape sequences have called for (changing the color, for instance), the escape sequence is printed to the screen!

The solution lies in doing the following: checking the escape sequence as the bubble does it's own logic; not in the lower level printing code. Then, when the time comes to draw itself, it will produce a proper-drawable string sans escape sequence data. This produces a slight bit of overhead in creating copies of the string to be printed, but it shouldn't prove to be too much to create a noticeable hit in performance.

I decided to tackle animated sprites first, since this would be much easier to transfer from Allegro into the new framework. The translation was pretty straightforward and is now complete minus "hitboxes" per frame in a sprite's animation. Bounding boxes, however, are currently working. One major change to the way animated sprites (formerly known as simple "sprites" or "managed sprites" in their previous form) work is that all their data is loaded from a single .plist file instead of between the image file and frame timings/bounding box data file. Loading everything from a single file has awesome benefits (no longer need to check that each file has its counterpart, etc). The only drawback is that the image data is stored in plain data format and cannot be easily replaced without using a utility tool to do so. This brings us to the new Beeboxer.

Beeboxer was my old tool for generating frame and bounding box data for the Allegro style sprites. There's a new version of Beeboxer in town which allows me to generate the same type of data and dump an appropriately formatted .plist file that the API can use. This time around, however, I didn't have to write my own UI widgets for controlling and changing animated sprite content. There are a few issues with Beeboxer as of this posting--one of them being that the image data cannot be replaced once a .plist file is generated. This is a matter which shouldn't prove too difficult to fix. Another nicety is integrating keyboard control of paging through frames and the starting and stopping of animation playback.

It shouldn't be too long before the first iteration of thew new Beeboxer is complete and I'll start looking at implementing scrolling text bubbles.

A few good chunks of code have been rewritten in order to handle more "gl appropriate" drawing. Both the tilemap nad the text rendering have been updated to take advantage of it. I'm still researching what I may possibly be able to do for sprite rendering, but since most sprites will use different textures (not all sprites will be pasted into the same texture), that will prove to be quite difficult.

Various other additions to the tile mapping functionality was upgraded, such as being able to draw the map at any given offset. Previously I had simply used hardcoded values starting at the edge of the map.

The two next things up on the plate are animated sprites and scrolling text boxes. These are two things that I have very robust classes for in Allegro. More likely than not I'll be gutting some of the internal code I have previously written and transforming it into a new style that will work with my new framework. Obviously, though, I'll hopefully be adding in some neat new features. One of these features I'd like to add is text bubbles that have built in support for advancing through "pages" of text. Previously this all had to be done manually.

All in all there's still a bit of work to do to get this framework up to speed with all of the nifty classes I had that extended allegro to do interesting things. Once it reaches that point, hopefully it will be robust and fast enough to potentially whip up a little something and see whether it's worth continuing on with it or not!

Over the past few days I've been dealing with a few assorted issues with this basic framework I've been working on. The most notable issue was a very large hit to FPS when drawing maps. My initial attempt was good, but I approached it in the wrong way when it came to actually drawing the tilemap. Now that the issue is (for the most part) solved, I realize that I need a bit more functionality when it comes to drawing things onto the screen.

My initial attempt at the tilemap used my basic sprite drawing routine to draw each tile individually. The main problem with this was repeated glBegin/glEnd calls; one for each tile being drawn! Fixing the map drawing so that it was wholly contained within its own begin/end fixed up the major FPS issues pretty quickly. There are a few other areas where optimization like this could be added, most notably the text rendering.

This leads me into other issues, like adding in features to do more proper drawing, which will allow for almost all rendering to be done within the same glBegin and End calls. Additionally, there are a few other things chomping up a bunch of CPU time that I need to look at.

I've added basic system timing to the framework. Currently it works as desired, but that doesn't mean it's perfect at this point. I'll need to throw a test build at some people and see how it performs. I also eliminated a rather annoying shearing issue. Hopefully this will be the last I see of that.

In addition to those (minor--as in they only took a few small lines of code to implement) changes, one other major component has been started: tile maps! The generic skeleton of tilemap work is done. Currently the maps are dynamically resizeable and can swap tilesets on the fly. There's still a bit of work that needs to be done in regards to tilesets (loading/caching them) as well as the speed at which maps are able to draw themselves. Currently there's a bit more computation that I would like that is calculated for every drawn tile (due to the nature of how the tiles are laid out in texture files). This leads to a bit of a dip in the FPS rate. Hopefully this can be easily remedied without too much work.

There is currently no support for layers, but this can be easily added in. Another missing feature is saving and loading of maps. Currently I'm simply generating a screen-sized map that can be manually modified. In order to make a proper map editor I'll have to figure out how to handle mouse events in Cocoa. It appears that they work much in the same method as the keyboard routines do.

Text output has been revamped quite a bit over the past few days. In the initial pass the method of text output was to have a compiled image to pull each character from. One of the limitations of this method was that each character was forced to be mono-spaced in both width and height. When using this style on a non mono-spaced font the results weren't very pretty. Too many of the characters were much thinner than the widest character, looking like a font that had entirely too much space. To break free from this restriction I came up with a scheme of being able to have multiple widths by simply supplying the start and end coordinates on the texture to the font class I had written. Writing such values by hand wasn't very ideal, so here is where I introduce FontCrusher; a neat little app which will take a specifically designed image file and dump the coordinates of the font characters in the proper format.

FontCrusher works pretty simply. It scans each cell in the preformatted image file horizontally until it reaches a prespecified color. Then from that point it scans vertically (downward). The process is repeated and the values of the width/height of each character cell are stored into the coordinate file for the given font image. The only restriction here is that the font texture image is required to have the characters appear in a certain order.

Since they are textured, the fonts look quite nice, utilize alpha values, be easily scaled, and also be easily color tinted. The only drawback is that when I want to use a new font I have to manually compile the texture image file and draw the colored grid that FontCrusher scans for. I'll be looking in to whether I can automate this process using some of the Cocoa framework or not.

An update containing actual progress? Amazing! I took some time to get back into gear with my native 2D Cocoa/OpenGL framework application to see if I could get past the hurdles I was previously experiencing. The framework will essentially do what allegro does, but offer the support of OpenGL for super-fast goodness. While I could always use Allegro extensions, I feel that this is a good way to learn some OpenGL specific development as well as, more importantly, Cocoa specific development. In trying to get textures to load I was having a whole slew of issues: the textures were always appearing a solid color instead of the actual image that they were loaded from. It just so happens that I've been using an extension that allows for non power-of-two texture dimensions. Unfortunately, I missed the memo where, when mapping the texture coordinates, the range of values is not from 0 to 1 as one would expect with the classic OpenGL calls. The range is, actually, from 0 to the width/height of the texture itself! Go figure! I was drawing a single pixel of a texture over the entire surface I was trying to draw to!

After solving this issue I quickly began adding some additional required features such as a music player/manager and a sound player/manager. Each of these managers handles keeping track of a cache of sounds and allows for dynamic file loading from the application bundle's resources. This means that I can simply call for the path to an image file located in the images subdirectory called "blah.png", and the full path to the file will be generated on the fly. This isn't working entirely as I want it to (it does not recur through all directories in search of the file), but for now it serves its purpose.

Keyboard handling was already in place before I ran into my texturing issue. With drawing, keyboard input, and sound output all in place, the next obvious route to go was text output (which isn't so straightforward). This is currently in the works, but I'm going to be using a texture mapped route to simply draw portions of a texture containing the letters I want in a sequence, making the appearance of basic text output. So far the basics are in place and the letters "ABCD" are supported. This method of font output is a bit of a pain since it requires me to construct a texture with all of the letters aligned in a specific format. It shall suffice for now.

So, as of right now, the beginnings of this framework support all sorts of alpha-enabled PNG goodness in the form of textures (with rotation!), as well as incredible basic textual output. Not depicted in the screenshot, obviously, are the sound capabilities.

For the most part, things seem to be shaping up into something I may potentially be able to use to make a game. Something I have yet to look into is setting up proper timing routines to keep things running smoothly on a range of machines. This will probably prove to be slightly more problematic than the simple Allegro timers that I'm used to.

The past few months have seen an absolutely bare minimum amount of work done at all, which is unfortunate. Classes are now over (for good, for the most part), which frees up a bit of time. Coincidentally full time work kicks in rather soon, so that freed up time will now be replaced (although not entirely) with work. Hopefully I'll still be able to put in some decent amount of time on some of my game projects.

Speaking of which, I have been going through a lot of debate regarding which direction the game development stuff will go in. I have that bit of a sidescroller framework in the works that is coupled to Allegro. I'm not sure if I want to continue with it or not. Recently (as in the last month or two) I have been working very minimally on some OS X specific stuff. For the most part, it's a simple framework for doing 2D game related stuff with OpenGL as its backend. Progress on that has been very slow mostly due to the fact that in the process I'm also learning all sorts of Cocoa and Objective-C specific stuff.

I could potentially work on both at the same time, but I'd really like to focus on one thing at a time. Whenever I work on Allegro specific stuff, I feel as if I'd like to try and shy away from Allegro and work on some platform dependent stuff (to gain some good knowledge in whatever platform I'm developing on, this case being OS X). However, it's easy to hit roadblocks when trying to do something that is incredibly easy in Allegro.

Lastly, since ZD I have been doing all of my own pixelart, which isn't of the greatest quality, due to lack of practice. This is something else I'd like to spend time on, but doing so obviously limits development time. Additionally, since I have much more practice in the programming side of things, any pixel work I do will be sub par in comparison.

All in all, there's plenty to work on but my focus just simply isn't directed yet. Hopefully after getting into the groove of full time work again I'll be able to find a comfortable zone where I can work on something (anything!) and make relatively steady progress.