Aerial spriting is coming along well. So far I have completed the "idling" animation. I began working on the "enemy appears" animation, but it simply wasn't coming out how I had envisioned it. Hopefully my next attempt will yield better results. After that, there are still a bunch of animations that need to be done: movement, special power up, special move, receiving damage, dying, and one or two animations unique to each of the flying enemies.
While it seems like a lot of stuff to do, I'll be recycling some aspects of the ground-based animations in order to, hopefully, speed things up.
There isn't much to report today. I put together the rest of the generic animations for the enemies that were missing them. This now leaves me with two enemies (both aerial) which need complete generic looking animations done. They will both share the same animations, just in a different color, for now. This is exactly what I have done for the other enemy types; minus the animations that are unique to that enemy.
At first pass, creating the imagery for the flying enemies is going to be a bit more tricky than their land-bound counterparts. Hopefully I'll be able to put together something that's on the same decency level as what I've done so far for the land dwellers, if not better. I'm not shooting for anything spectacular but rather, as I've said in many previous posts, something that appropriately gets the job done.
The generic animations have been put into place for four of the enemies. There are still a few sprites that aren't shared between all of them that need to be whipped up. In doing that chunk of work I can already see how incredibly useful Beeboxer and the bbx format is going to be for using sprites in the game (and any game in the future). Editing can be a slight pain: constantly updating a datafile with given data--but that's only because I insist on using the grabber tool rather than the command line "dat" tool. I may consider learning the ins and outs of dat to make life easier when it comes to updating data.
With this done it's back to drawing more stick animations. I'll be needing two for the flying type of enemies in the game as well as some for the more obscure and unique actions certain enemies take. Then, with that complete, I'll be moving onto making the enemies a lot more interactive. That is, when they take damage they will recoil instead of just blinking and moving along. They will also fall to the ground when they die (obviously using the previously created animation). I'll be making their limited AI a bit more sophisticated to be less unrelenting on the player.
It appears that the issue regarding reading files directly from datafiles is, in fact, a bug in Allegro. For now I'm using an alternative that I'll probably just stick with. The bbx files that are generated are in the size range of less than 500 bytes, so I'm not too worried about not being able to use compression on them. The response to my thread on AD came through pretty quickly, so I never did get a chance to clean up Beeboxer's code. Of course, I could have done cleanup anyway, but...
Since Beeboxer was working correctly and writing bbx files I couldn't help but start putting together some data for use in the game. Creating sprite data is now a complete breeze. There are a few things to be desired in the form of shortcuts for Beeboxer, but overall it's an incredible improvement over the hard-coded method I was using previously. I created data for one enemy's set of animations. The generic stickman animations I created didn't cover all of this enemy's actions, but it did a pretty good job. So far only the animation stuff is implemented. I have yet to test out the real reason behind beeboxer: bounding box data per animation frame.
If all goes well I'll be modifying the generic stickman to represent all of the available enemy types that share the same types of actions. Flying enemies, for instance, will need a new set of generic stickman animations.
And lets not forget cleaning up and prettifying Beeboxer. That's very low on the priority list, however.
For everyone having problems loading custom level sets in Zep's Dreamland under Windows, I have put together a patch that should fix your issues. Head over to the
ZD page and try out "Patch A!"
The coordinates issue regarding the bounding boxes was an incredibly easy fix. All it required was subtracting off the offset at which the sprite was drawn, and then reapplying it when drawing the bbox onto the screen. Simple! I didn't expect it to be any more difficult than that, anyway.
Once finished with that, I decided it was time to whip up a playful little icon for the application. It's fitting, I think. After that , I wrote the saving and loading routines. The bbx format is in place and everything works perfectly fine. It's awesome to be able to load in all the special data pertaining to a sprite straight from a file. It's very easy, and will make integrating sprites into the game 100% more simple than it is right now.
Unfortunately, I'm unable to actually use it in the way I want. Currently I'm writing out the frame data using Allegro's packed format. While reading this file straight from disk works fine, reading it directly from a datafile does not work properly. I have my suspicion that this is a bug in Allegro, but I can't be certain. I've contacted AD and hopefully will be able to find out soon whether what I'm trying to do is not supported, or actually causing a bug to surface. Currently, I'll have to wait before I can fully integrate loading bbx data from the game.
In the meantime I can do some much needed cleanup all around for Beeboxer in terms of UI as well as messiness in the code.
More Beeboxer updates! Bounding and hit boxes are now editable on a per frame basis. Currently, only a single bbox and hbox can exist for any given frame. The different between a bbox and a hbox is simply the ways in which I will use each. A hitbox is, technically, just a bounding box. "Bboxes" will be used for any general bounding I will be using in my game. "Hboxes" will be used for more specific bounding, including things like attacks. When an enemy attacks I need an extra bounding box that will form a "hitbox", or the box that I will do collision checking against. For example, in a punching animation, the bbox will be used to outline the general shape of the body, while the hbox will be used to outline the fist along its path during the punch.
I intend to leave restriction on h/bboxes at one per frame, simply because this is all the functionality I need right now. The game currently doesn't require multiple bounding bounding boxes used for the same purpose (that is, general shape of body and general shape of subparts used during attacks).
The actual editing of the bounding boxes is quite basic. With bbox or hbox editing turned on, simply click within the bounds of the given frame being shown for a sprite. Then, drag the mouse. A box will be constructed from the initial point to the current mouse location. Click again to confirm the final geometry of the bounding box. It's that simple!
The whole scheme isn't entirely complete, however. Currently the bounding boxes are using absolute screen coordinates. These coordinates need to be changed into sprite relative coordinates when being stored, and converted to screen coordinates upon drawing. Once the coordinate conversions are complete, I'll be taking a look at the first implementation of saving/loading of bbx data.
Beeboxer is progressing steadily. Image loading is complete, as well as choosing how many frames exist for a given animation. Basic controls for playing an animation are in effect, including paging a single frame forward, and back. Frame time delays are also editable. Basically, everything is in place to create frame data for my basic ls_sprite class. To be honest, I'm quite surprised that the functionality to drive the bare ls_sprite class is done minus transparency toggling. Of course, I haven't written the saving and/or loading functions that will write/read this data, respectively. One of the main reasons that isn't done is simply that the ls_sprite class doesn't support reading parameters from a file, yet.
The main point is that ls_sprite will be extended to make use of the bbx file format (yet to be written). Most likely this extension will be in the form of a wrapper, as opposed to making the base class itself capable of reading bbx files.
In the updates I did today I ran into some issues. I was getting double frees all over the place and I couldn't, for the life of me, figure out why. There were two main causes for this problem. Initially, I was internalizing the bitmap data for the sprite used to show the animation on the screen. This means that it keeps a copy of the image data internally, rather than simply a pointer to image data managed by someone else. In the Beeboxer code I am frequently destroying and recreating that sprite. This was causing major double frees. The problem here existed in the dtor for ls_sprite. I was inadvertently destroying the bitmap data, regardless of whether it was internalized or not. This was a big no-no. If an outside source was managing the bitmap (eg: ls_sprite was just using a pointer), it definitely should not have been destroying that image data.
After realizing this blunder, I had realized that I didn't want to internalize the image data anyway. I needed to keep a copy of the image data for when I was destroying and recreating the sprite. Instead of copying out the image data, I figured it would be easier to just keep a copy of it around for the purpose of the creation/destruction of the display sprite. In passing the pointer around I failed to ensure that any changes to the pointer itself would be registered outside the function. Woops! This means that I was destroying a bitmap at a given location in memory, but when "recreating it," the pointer was only modified locally, instead of propagated upward to the caller of the function. This, in turn, lead to even more double frees.
Needless to say, that's all sorted out. Beeboxer now sports properly editable frame delay timing, frames per animation, as well as play/pause and forward/reverse functionality. Quite spiffy!
I've started work on the creation of the new Beeboxer. It's coming along quite well. One of the things I knew I would need before I started was an editable text entry field. I really didn't want to use the Allegro dialog stuff just for that, so I created my own. It works much the same as an allegro editable text field, except it's 100% more easy to use (for me, at least). I also quickly whipped up a simple textual button GUI widget. With those two integral pieces put together, I started building up the new Beeboxer.
If all goes according to plan, what it will essentially be able to do is load an image to apply frame count, timing, and bounding box information to, and then dump out the specific Beeboxer format file which contains all that information. The sprite class I have will be extended to be able to read in Beeboxer files and apply it to itself. This will allow the user (that's me) to only have to supply the bitmap image as well as the Beeboxer (let's just call it bbx) file, and everything else is handled automatically. This will save me a lot of time in the long run. How I'm storing frame data currently is just horrible.
That's it. Beeboxer's purpose is very simple, but it's going to be a bit complicated to pull it off correctly. For instance, any time any information about the sprite is changed, I'll have to dump the current sprite being displayed on the screen and create a new one with the changed parameters. I also need a sensible method for the user to be able to flip between frames as well as be able to start and stop the animation. Then, there comes the bounding box creation. This is going to be the biggest toughie of them all. What I'd really like to do is allow for an arbitrary amount of bounding boxes to be associated with any given frame of the animation. However, what I think I will do is simply start out with a limit of one bbox per frame.
I will also need to take into account that when a sprite is loaded, it has no frame information. When this happens, the entire image is shown on the screen. Due to the way that my sprite sheets are set up (each frame side by side in a single length run) it's very probably that many sprites will span the width of the screen. This is going to require some behind the scenes work to resize the final output image onto the screen. This would be easy if one of my custom sprites could draw itself scaled, but unfortunately they can't. Getting this to work properly is going to require some clever trickery.
Good news, bad news, whatever it is, it means there's a lot of work ahead. Beeboxer works properly and that's great. Unfortunately, however, using the data it outputs is a bit clunky, at best. I implemented a subclass of my sprite class to utilize the data, but in doing so I realized some really huge flaws in how I have been using my sprite class. Currently, it keeps no local copies of any data (that is, image data, frame timing data, etc). The purpose of this was to allow usage of data from datafiles that are preloaded and stay resident in memory. Since I was using this method of things, I was taking the painstaking approach of just keeping all animation data within the game code itself. This is really bad, and it's about time to fix it, which is what I intend to do.
Firstly, I need to extend the basic sprite class to be able to keep resident copies of all data it needs in order to perform its operations. This means it will have the ability to create a copy of the image data it uses as well as the frame timing information. Secondly, I intend to create a "managed" version of the sprite class. Incidentally, I wrote a managed version of the class a while back, but it in no way will perform the tasks I need it to. It also isn't crossplatform (it is not endian-aware). A rewrite will be required.
What the new managed version of the sprite class will do will read in a specialized file in addition to the original animation bitmap. This file will contain all the information necessary for setting up the sprite, and also include extra special information. It will house the number of frames, frame timing info, and bounding box information (per frame), among other things. Of course, I will need a tool to generate such information given the bitmap data. This is where Beeboxer comes in, hopefully.
I'd like to extend Beeboxer to, instead of reading a specialized masking image to generate bounding box data, read in the original image and allow the user to input frame timing data as well as create bounding boxes on the fly. This might be a bit much, but I'll be exploring the viability of turning Beeboxer into a much larger and more robust tool than it currently is. The only thing I see being a problem in an advanced version of Beeboxer is input from the keyboard in the form of fillable text fields. Unfortunately, Allegro is kind of lacking in the editable GUI element department. I'll have to determine if writing my own basic GUI text entry widgets would be appropriate in this situation.
I don't want to be spending an inordinate amount of time doing this extension work, but I do think it is rather important. With the whole set of changes described above, the game codebase can be cleaned up one hell of a lot--and that's always a good thing. It would also mean I can potentially change sprite data and information on the fly without recompiling the game. Ah, that would be grand.
Today I'm going to break the spriting trend, so unfortunately that means no pretty sprite to look at this update. What this means, however, is that I finally got to delve into some coding after a pretty long hiatus. A little burnt out by creating sprites I decided it was time to start implementing this auto bounding box stuff (also referenced as "hitbox") I've been talking about for the past few days.
I initially implemented it to be calculated "on the fly," but testing it out on a very simple, four frame animation proved to be incredibly too slow (due to using pixel operations on the mask image). With that idea shot down rather quickly, I had to come up with an alternative method of obtaining the bounding box information from a "masking image." Let me first explain what I mean by masking image. In the new auto-calculated bbox scheme, each animation will be accompanied by a masking image which will both be of the same dimensions. On the masking image I simply draw a rectangle (filled in a single color) which will be the bounding box used for the sprite for that given frame. I can then look at this masking image and calculate where the bounding box for the current frame is. Doing things this way removes the necessity to hard code bounding box values for every single frame of every single animation.
The problem I was facing now, was that the bbox information calculated from the masking image could definitely not be done on the fly. I would have to precalculate it somehow and store it for later reading. I would have liked to have tied it into the image itself, but that just wasn't possible without major code rewrites. Instead I am going to try the path of having a "mirror" datafile which will house bbox coordinate information for every frame of a given animation. Then, upon creating a sprite in the code, I can simply go reference that datafile and extract the bounding box information I need.
Of course, the bounding box data still needed to be calculated. This is definitely something best left to machines to do, rather than painstakingly entering things myself. I put together a nice little tool that will, given a masking image, the dimensions of the frames, and the total number of frames, will dump out a formatted file containing the bounding box coordinates for each frame in the animation. Awesome! I'm making things sound much simpler than they actually are, though.
Apparently, Allegro application bundlers under Mac OS X are unable to parse more than a single command line argument. While application bundles aren't evoked from the command line, dragging files onto the application bundle is essentially the same as "providing it with command line arguments." This meant that I couldn't simply drop a whole bunch of masking images onto the app. I would have to do things one by one. Very annoying. Instead of waiting for a fix to be implemented, I simply worked around the problem. I threw together a nice little python app that would serve the purpose of gathering up the items drag/dropped onto it and passing those to a command line version of the bbox dumping utility I created Obviously, I still have some details to work out. Currently only a single hitbox can exist for a given frame. I'd like to increase this amount in one way or another. I also have to finalize what the formatting of the output file will be.
The toolset has a simple name. Originally it was "bboxer," but I decided that "beeboxer" is a bit more fun. While I'm not going to set it up for distribution or anything like that, I'll still probably create a unique icon for it sometime soon. Beeboxer will then join the ranks of Pack, Unpack, and S.trip.
There's not a lot to report today. I went back and fixed the punching sprite to look a bit more powerful, and have a nice, long reach. This definitely has the effect I'm looking for: a lunging punch. With the help of some wonderful people over at #gdr (mainly the madgarden) I was able to produce this nice looking sprite. There's still much to be desired, but it runs circles around the old punch. That said, I still think I may yet have a use for the old punch. I'm not going to put it out of commission yet.
This sprite is a bit wider than the rest, and because of that I'll need to do some extra work when I throw it into the actual game. This brings me back to, again, potentially extending my sprite animation class to additionally handle doing its own "hitbox" calculations. It would make things one heck of a lot less tedious.
I whipped up a damage taking sprite, a dying sprite, and, unintentionally (while trying to make a damage taking sprite), a blocking sprite.
This was originally going to be the taking damage sprite, but after some review and helpful words from a few friends, it made sense why this made a pretty bad damage taking sprite. I'll keep it for now. I can see it potentially being used for a backwards dash of a certain enemy. When thrown in game, the backwards movement will be much quicker, looking like an actual dash instead of the weirdness you see here.
Here is what I will, for now, use as the damage taking sprite I stumbled upon this one while looking at the death sprite. I simply took some of those frames and played them in a different order. It worked out pretty well.
The death animation. I'm not incredibly impressed with it, but it will get the job done. Yes, I did go with the "melt into the ground" style death. I think I can be forgiven in the first round of spriting!
In addition to that, I got some pointers on how to make the punching animation a bit better. Even with the swoosh attached, the punch simply doesn't reach far enough to prove effective. What I would really like is a sideways stance where when the enemy punches, it will move it's back foot to the front in a wide lunge. Given the current sprite size, this might be a bit difficult. That said, there's nothing stopping me from using a larger sprite size for the punch other than the fact that leaving it the same size as all other sprites is the least amount of work when integrating it into the code.
I'm beginning to consider implementing a way to gather bounding box information from the sprites themselves instead of having to code that stuff by hand. More updates on that to come. For now, I'm envisioning a double sprite set, where one image is the animation itself, and the other is a bitmask of the region within the sprite that is the "hitbox."
Damien has made a few cosmetic changes to his level set. If you have a previous save for the last level in the set, this new set will cause the game to fail at loading. If you experience this issue, please contact me and I will step you through how to resolve the issue.
As for joystick updates: none yet. In lieu of being able to do some coding on that front, I whipped up two more generic stickman sprites for use when I start to code proper AI. As usual, they're super rough -- but they definitely get the point across. The first one pictured here is an "appearing" animation. Each enemy will have their own unique version, but this will work well for now. The second is a basic walking animation.
I did a test in Windows land to see if the joystick issue I observed earlier was reproducible there. It wasn't. Currently, I do think it could be a problem with the OS X code. I've emailed one of the OS X developers who will be taking a look at it to ensure that everything is working properly. Hopefully this is now how the joystick should operate--I would like it to operate in OS X how it does in Windows, pressing and then releasing the DPAD-Hat does not leave the axis in a "sticky" state.
In other news, Damien has sent in a revised version of his
level set which features an additional new level, among other things. Be sure to check it out!
It appears that the file_exists() issue was cleared up a lot sooner than I had anticipated. With that patched up, I grabbed and rebuilt the latest copy of Allegro. I was glad to see that no other issues are readily prevalent. I didn't, however, install the library -- so for now I'm building my project from the command line in a bit of a hackish way, since I don't have a proper makefile for it (that's handled by Xcode, which takes care of a lot more than just building eg:bundling).
With a newly built version of Allegro that fixed the gamepad issues I went ahead and started finishing my implementation, which was effectively left at detecting which stick to use for movement input. Unfortunately, it looks like there is still some breakage or ill-effects. The analog sticks work properly, but when I attempt to use the DPAD hat for input, after pressing in any direction, that axis becomes stuck-on at full value. So, for instance, if the hat hasn't been touched yet, the position on the left/right axis rests at 0. If I press to the right, the position changes to 128 (the maximum value). After I let go, however, the position doesn't change back to near 0. It simply stays at the maximum. Somehow I don't believe that this is normal operation. I'll be trying out some test code on my Windows box to see if the problem is either my gamepad itself, or the newly modified OSX code.
The skinny stickman version of a swinging jab
The same animation, but with a body thrown on
A bit of a touch up. The main purpose of this was to extend the range of the punch. Without the power swoosh, the punch itself would be too close to the enemy's body bounding box that it would be a pointless maneuver.
In addition to the punching animation I also whipped up a special move animation. This is the combination of the "startup" animation as well as the "I am now using a special move" animation. This particular animation is the worst out of the entire bunch made so far. That said, I probably won't polish it up any more. It gets the point across well enough. It's definitely useable.