Minor update, but still one worth mentioning. Sprites are now able to be drawn horizontally, vertically, and both horizontally and vertically flipped. I still have yet to test out frame offsetting, so this is the next course of action. Frame offsetting is the ability to say that for any given frame, it should be drawn with an offset in x and y directions from where the user specifies an animation should be drawn. This should be useful later on when I have something like an object which has frames that aren't all the same dimensions. This allows me to use that object's x and y positions normally, and just offset the larger or smaller frames to appear in the "correct" position relative to where the rest of the animation should be playing. Doing things in this way really helps in removing the need for objects to know the exact dimensions of the sprite animations that they use.

I can't say for sure that the lack of updates was purely because I was having fun spending time playing games or whether it was because I (subconsciously) simply needed a coding break from what I was working on. At any rate, I hopped back onto the development train and started fleshing out the animation class so that after loading the animation information it could actually draw something to the screen. This is now working properly, but is slightly limited. We can get to the limitations later, though. Firstly, some bug information.

In trying to get the sprites to display themselves I noticed that frames were simply not drawing correctly. For instance, they would draw always starting from 0 as the reference, and sometimes would actually change to some random values I wasn't expecting. There were two bugs here causing this to happen. The first was simply assigning the wrong value to the wrong variable. Instead of grabbing the proper top coordinate of a frame, I was inadvertently setting it to nothing and setting the bottom coord twice.

The other bug existed in the loading of sprite information from the animation file. Apparently the dummy data that I supplied wasn't good enough for a test, because the initial x coordinate of every frame was starting at zero! I missed incrementing a string pointer, so when calling strtok I was getting a whole bunch of garbage between the line start position and the first token, resulting in garbage that couldn't be converted to an integer. Long story short: the pointer is now set to the right position and everything falls into place.

So, animations are working fine, but are currently missing a bunch of niceties like horizontal and vertical flipping. Additionally, I haven't put the reading of bounding box data to use yet. All of these items are pretty minor and are actually trivial to fix. Once they're done I'll have to do some major cleanup to the main function, as it's now cluttered with a bunch of random single sprite testing code.

It's been a big chunk of time since last post, but there really isn't anything to report. I suppose you could say I've been doing a lot of "research" recently; and by research I mean playing games more than I'm working on developing them.

The parsing of metadata in regards to sprites is now complete. All the data read in is now actually stored in memory rather than just printing itself out and being forgotten immediately (done mostly for testing purposes). The structure itself is slightly complicated, but I think that in end end it's worth it. Currently the sprite class defines an animation class, which in turn defines a frame information class. While all of this could be at the higher level of the sprite, I like keeping things separate. This will help decouple stuff like generic animation from sprites. While currently sprites are the only thing that do animations, I could more easily separate this out and use it elsewhere. That is, if I have a more general use for animated stuff that exists outside of a sprite I should have an easier time getting it to work.

Aside from that, I did a quick run though the code to do some general cleanup. I added a class to facilitate writing information to a log, and converted all the printing to stdout to dump to the logfile instead. This is really useful now, and moving into the future. I'm debating whether I will modify my printing methods on objects to dump to the logfiles as well. The printing functions are incredibly useful, and essentially just print out data pertaining to a class in human readable format. For instance, to check that sprite data is properly loaded, I can tell a sprite to "print" itself, and all pertinent data and information will be printed out to stdout. I think it may be useful to add a parameter to the print method that dictates where it should print to: stdout or a given log filename.

So I took a pretty decent design for storing sprite data and ran with it. I still think it needs some modifications, but now I do have a basic loader that can read various sprite related data from a plaintext file. Currently I'm allowing for a single file to be able to specify information regarding multiple sprites that are derived from the same base image. I'm not sure if this is the final method I want to use, though. Before I get into details, let's get one thing straight first.

When I mention sprite, I mean either a static, or animated image that can get drawn to the screen at an arbitrary position.

While it's nice to have the metadata for all the sprites that are generated from a single image in a single metadata file, I think there may be something to benefit from having a separate file for each specific individual sprite. For one, it prevents having to read superfluous sprite data if all you want to gather information on is one specific sprite. Doing this kind of separation means more management on the developer's side (the one who is loading all the individual sprite files). I will most likely go the route of multiple files. Because of the versatility of the resource manager, having multiple metadata files referencing the same underlying bitmap image won't be a problem at all.

The really neat thing about how I've set up the system is that if I want to use bunches of separate files I can already do so with how it's currently set up. There are a few minor things that have yet to be done (like putting the read-in data into some sort of structure I can actually use). So, all in all, the reader will work for both methods, and I can choose which one I want to use when it comes down to the time when I can actually start using the information. That brings us to another topic...

There is currently no code to handle drawing of sprites (as I have defined them) yet. It will be a while before I can test out the metadata loader and how it holds up when a bunch of files are requested for parsing. And, as I have already said, I need to figure out just how I'm going to store the data that I'm reading in. It shouldn't be a lot of work. Allowing multiple sprites to be defined in a single file just means that there will be a slight bit of overhead on the caller of the loading function for the metadata in order to parse out the results (since there could be multiple sets of data).

In putting together the basics of the player class, one of my most dreaded tasks finally needed to be tackled: jumping. While I have no problems actually programming what is required to make it happen, I have the hardest time timing everything just right so it feels natural. Of course, I'll fire up a bunch of classic games and see just how the jumping feels, and then try to mimic what I find will work best for myself. It's a little hard when all you've got to work with are solid colored tiles and a bounding box for what will eventually become your player, but I think I've come up with a pretty decent version of jumping for the time being.

Once I have some very basic animations sorted out I'll be able to see just exactly how it feels. More likely than not I'm going to have to do a bit of tweaking and modification to get the desired height, length, and hang time.

Before I can actually put some animations in the game, I need to be able to handle them. As some of the long-time readers may know: I already have a class that does this. So, why am I attempting to write it once again? Well, the answer is simple. While my old method works quite well, it doesn't play nice with having the entirety of an object's animated states contained within a single image. That is, for various different states of, say, the player, I would have to have an individual bitmap. What I'd like to do is have a large complete sprite sheet that I can just pull from. While that in itself isn't very hard to do, I would like to have a nice and useful method of determining where to clip images from, as well as what the frame timings are. Additionally, I may like to have bounding box data available as well. In the past I've written editors to do this kind of work for me. This time I'm considering reading straight from a hand editable file. As will all things, I'll have to take some time to spec this out and come up with a good design.

There has been a bit of a lull in terms of development. After patching up the resource manager and adding a few more changes to the codebase, I thought it was finally time to get some serious design stuff out of the way. I wanted to spec out a bit more information than simply that the game would be a 2d platformer that is exploration based. While that's all fine and useful--I already knew such information.

So, the beginnings of some deeper design regarding game specifics now exists. It's not at the stage yet where I'd like it to be, but it's a start. Using that, I can create some sort of mini implementation of how gameplay should work. Currently I have a few design details posted up for some review and feeback, but the response hasn't been great. Hopefully some kind of limited version of the game to let people get a feel for how it should work will yield better results.