New Animation System in Place

Initial tests indicate that I may have finally gotten the new animation system working properly...did I mention I'm not very good with math. Anyhow, as an added bonus it appears, believe it or not, that the collision system may be working as well. (I never saw that coming, but I'm not complaining.). But those are VERY initial tests in both cases.

So here's a brief history of the animation system throughout Deep Blue's development.

I. Square Sprites - The initial system was gleaned from the platformer demo in the Visual Studio Express Dev Library. It was the most specific, and limiting of all. It ONLY accounted for square sprite frames (with a 1:1 ratio) layed out in a horizontal line. While this may have worked perfectly and been very efficient for the platformer, you can imagine the limitations it put on sprite design.

II. Variable Ratio Sprites - So, the first thing I did was overload the method with an alternate version that accepted a frame width. I kept the sprites aligned in a horizontal row so that the frame height could be simply pulled from the sprite texture height.

That worked pretty well, except on the larger sprite animations which resulted in extremely long sprites (250 pixel wide frame * 30 frames = 7500 pixel wide sprite). And that just wasn't going to work. Even though it wasn't recommended, things animated pretty well....until the engine started checking for pixel collisions on a sprite of that size. It pretty much brought the game to 2 to 3 frames per second. So after posting and talking with the helpful crew on the XNA forums they suggested a basic rule that no sprite should be larger than 2048 in any dimension, and really, you should shoot for a 1024 max in most cases.

In order for that to happen...other than reducing all my larger animations to 3 frames....I had to lay out the frames in a square spritesheet.

III. Square Sprite Sheets - So my current solution is to lay out the frames in a 1:1 ratio sprite sheet with a max size of 2048 x 2048 pixels using a 1024 x 1024 texture when possible. After loooooooooots of broken math it appears to be working. So now I can have much more efficient sprite sheets and much better frame rates when lots of things are moving on the screen at once.

Each of the above variations was carried out by overloading the same Animation constructor so if I HAPPEN to have an animation that has 1:1 frames that is not over 2048 pixels in texture size I can create it easier than I can the custom square sprite sheet constructor.

All-in-all I'm pretty pleased with the results. It took a little longer than I'd hoped to figure it out, and I went through a bottle of Tylenol in the process but I'm glad to have it out of the way.