Things have been slow lately, but I've been playing around with getting the previously mentioned sprites into the game in one form or another. I've made a pseudo player class so I could play around with the animation and see how smooth it looks. I'm quite impressed. In doing so, I found even more functionality I could add to the ls_sprite class. I completley missed the fact that I would want to be able to draw flipped sprites (horizontally, vertically). Adding this functionality was rather trivial but leaves something to be desired with my sprite class. I'm not sure whether I want sprites that aren't drawn with transparency to be able to be flipped, since doing so requires some extra work and bitmap creation that is simply just pure overhead. I'm not sure whether I want to restrict sprite flipping only to transparently drawn sprites (basically sprites that will make use of the draw_sprite function which comes with it's own flip variants) or not.

There isn't any news on the coding front today, unfortunately. I did, however, work a bunch on the visual side of things. My pixeling skills are definitely getting better. Even though I will hopefully find someone with true talent to do the art for the game, my programmer's art is at least decent to look at! I now have a slew of sprites ready to be plopped into the game when the code is in place for them. Seven of them are now animated, which is definitely a plus. I'm learning a lot about the pains of trying to animate things in such a way that is actually looks natural and "believable", if you will.

I don't plan on taking too much extended time to do more sprite work, but I want sprites that are pleasing to look at when testing out the code I write. It helps to keep me motivated! It also helps for when I want to toss out a decently looking demo, as well.

My sprite class got a little more functionality added to it today while I was working on fleshing out my base object and another object that derived off of that base object (which I won't reveal since it will give things away). I realized that knowing what frame of the animation that the sprite is currently at is a pretty important piece of information. Also, it only made sense to allow animated sprites to either loop, or not. Both of these little tidbits were added. To tell you the truth, it was extremely simple and it will really make life a lot easier down the road. One really useful usage of knowing what frame is currently being played is transition animations. Say, for instance, there is an animation playing of a character running. Now say that we want to play a special transition animation from running to jumping, but it depends on what running frame is we are currently at. Being able to grab the currently displayed frame on the fly will allow for some neat things to happen.

As for the looping and non-looping, this was something I just happened to let slip through my fingers. All that matters is that it's there now. I still haven't fully decided how I'm going to implement non-looping sprites. So far I've decided that once the sprite is done animating, even if you tell it to draw via it's own functions, nothing will display, since the sprite has reached the end of its animation. There is a handy reset() function which will start the animation over. What I'm struggling with is whether to simply keep on drawing the last displayed sprite, or to draw nothing at all. I think not drawing anything at all makes a little more sense, but I just may have to see which method is easier to program with.

In the land of the base object, I finally pinned down what I want it to contain, and that is simply x and y coordinates on the screen, and a few functions to access and set these variables. That's about it. I was contemplating creating a single sprite pointer encapsulated into the base object, but I figured since each class that derives from it is going to have special needs, and I'd rather not have the "main sprite" named the same in each class, I decided against it. However, being able to derive just from this base class makes life easy, since I can plop pointers from any object derived from the base class into a container of type base class pointer. Simply put, if I wanted to (I have yet to decide my strategy), I could take every single object I create and toss it into one big vector. Using this method I could just iterate over one vector and tell every single object to go ahead and do it's logical computations as well as draw itself. I will probably have some kind of level of separation for object containers, however.

All in all, things are coming together nicely and I can start crafting more game specific objects now, which is especially fun because they produce visual output while I test them out. This is definitely more fun than writing a bunch of code that produces no visual output whatsoever!