Intermission #2 – Code Changes

Since we are moving from single images stored as frames looped together to a single image with a picking rectangle, we need to update the framework.

This involves:

  • Changing the make-up of a frame to use rectangles instead of textures (to identify the portion of the spritesheet is for each frame)
  • Adding a texture to the Animation class (for the spritesheet) and updating how it uses frames
  • Moving Drawing code in the Sprite Class to the Animation class, just makes things a little easier.

I’ve also done a bit of house keeping in the code, nothing major, just grouped all the private elements of each class together, grouped all the properties in the class together and put the constructors at the top and the main methods in the middle.  These are always good practice when writing

Source updated for Final combined update project for GS 4.0 project here on Codeplex (Windows and WP7)

Frame Struct (in the Animation.CS)

All we did here was to change the Texture property and parameter to a Rectangle (rectangles are how we pick sections of images, more on that later)

Before change After Change


And then updated the constructor likewise



Animation Updates (animation.cs)

The animation class in this approach is the most affected class, it has to be the workhorse for the animation, even if there is only 1 image and no actual animation.

The basic principle is simple, store a texture and depending on which frame is to be rendered, pick that portion of the texture and display it on the screen.

The first change is mainly for performance reasons, Lists are all well and good but they can (if used incorrectly) cause memory and garbage problems through what is referred to as boxing and un-boxing (basically where the values stored in the list have to be converted or stored in slower memory space, see Shawns “Garbage collection nirvana” article for a clearer picture and garbage collection – basically it’s bad and you should try to avoid it).  If you don’t use strongly typed data or classes that can be easily broken down (basically anything that is not a Struct with the default types or default types themselves) then it causes it to slow down.  It’s not by much but in high performance games even a 0.1 second delay from slow code can cause issues.

In the DigiPen tutorial however, we are using a strongly typed Struct (the frame) in a list, however since we have limited each animation to only have a specific amount of animation (it’s not going to change, the texture isn’t going to create more animations), we don’t need the extra overhead of a list.  So I’ve changed the storage type to an Array instead.  It goes back to old principles of keeping it simple and only use power when you really (really) need it. (in short the KISS principle all over again, you might hear that a lot here!!)

So where we originally just created the list for the animations for the sprite:

We now have an Frame(s) array, plus a few other attributes for storing the texture for our spritesheet (image) and some attributes about that texture.

Next is the biggest change to the animation class, from:

To this:

Here we have changed the constructor for the animation to expect a texture (our spritesheet), we then have some overloads for the constructor to make our life easier when creating Sprites (with or without animation, see the updates to the game class).  They all call a finalisation function to generate the frames for the spritesheet.  As stated before if the sprite has only 1 image in the texture, it’s just an animation of 1 frame, this enables us to use the same logic regardless of how many frames a spritesheet has.

This way of making everything act the same (with a few key differences) is a core principle when programming in C#, be sure to read the sections in the programming guide on inheritance and object oriented design, else you will end up writing three (or more) times the code you actually need.  It comes down to this, if you have to handle Oranges, Pears, Apples and Banana’s in your application, you could write separate code for each.  However since they are all fruit, you could write all the functionality for handling fruit, have each of the items inherit from the fruit class and then just extend for each type of fruit where you need to.  A very basic example but something worth keeping in mind.

In the GenerateFrames function, we interrogate the image provided, divide the width of the image by the amount of Frames you created the animated sprite with, which gives you the frame width.  then it constructs rectangles around of each frame using these values.  These rectangles become the portions of the spritesheet for each frame.

Now this code expects each frame of the animation to be completely horizontal (in line with each other), it doesn’t let you have multiple lines of images.  However the code in XX’s tutorial does do this, so you can adopt this method if you need it.

The last change to the animation class is the adoption of the code to draw the sprite to the screen.  I moved it here for simplicity, the class had better access to most of the parameters required by the Spritebatch/Draw function. (check the help for more information on the Spritebatch class)





Sprite class update (Sprite.cs)

The spite class is really more of a container rather than handling the drawing of spites to the screen.  This is a common practice (like I mentioned earlier about inheritance and such).  In this we only track where the sprite should be drawn, if it is active or visible and any transformation or collision logic.  (the sprite class is the brains, where as the animation class is the looks)

As I mentioned earlier in the animation class, I removed the Spritebatch Draw code and replaced it with a call to the current animations draw method.



I also updated the constructors to make the sprite class easier to use with animations, this just made it simpler to create new spites, especially if they only had either:

One image (like the background)

Or 1 animation sheet (like the Trooper)

This just makes the main game code easier to read as you will see below.




Main Game Code (StartrooperGame.cs)






In the main game code, we need to update the “LoadResources” function that loads all our assets to now use the new methods for Spritesheets


For the Background, we updated it from:


Although to do this since the Background is a class derived from the Main Sprite class, we also had to add another constructor to the StarTrooper Background class just to make use of the new constructor in the Sprite Class

Simple enough.


For the Trooper we see a bit more benefit from all these changes, since it has many images as part of it’s animation, this went from :


Hopefully you see, this is a little easier to read (and if you have more players, easier to manage 🙂

As with the Background, we needed to extend the Trooper class (in the StartrooperSprites.cs file) to make use of the new constructor in the main Sprite Class:


Lastly, the Condor.  Now this doesn’t make use of the extended features above as it has two animations, so we still need to manage adding the animations manually while still updating to now use the spritesheet functionality, this results in going from:


Still a lot cleaner and easier to use, if you add more enemies, depending whether you have one or more animations, you can use either of the two methods above,  Since the condor isn’t making use of the sprite enhancements we don’t need to modify it.

Now I’ve left it this way to show the different ways you could apply this, personally I would of made the condor and the explosion separate sprites so the explosion could be used, this simplifying the condor class implementation and letting use use the explosion for other objects in the game. (Although I may do this later after the main tutorial has finished.




I’ve not gone through the clean up here, you can browse the updates to the project in the download, I’ve even included the un-cleaned up version for reference if you are interested.

I will point that this is only one implementation of using spritesheets based on updating the original DigiPen framework only.

As I mentioned in a previous post, there is another god tutorial on Spritesheets over here and let us not forget the Platform Starter kit included with XNA GS 3.1, which uses spritesheets for all it’s animations.

There are a few limitations to the implementation here (and in both the other samples I’ve mentioned)

  • You can only have 1 animation per spritesheet (even though in this project there are properties for specifying different start and end frames, applying them effectively is tricky, try it if you wish)
  • Compiling several animations using different sizes is not supported, You also cannot put all your sprite assets on a single sheet (which would be very beneficial).  There are other implementation’s like Nick Gravelin’s Sprite packer, but they don’t support animations.  Feel free to enhance these and some up with you’re own monster one if you wish, but this breaks the KISS rule 🙂

Well enjoy play and have fun, on to the next Intermission.

%d bloggers like this: