Duplicating sprites
The SpriteLibrary can be used anyway you can get it to work. But it was designed to work by making master sprites, and then using copies of those master sprites whenever you need a new one. So you want to begin by creating Named Sprites
When you are ready to make a copy of, and use a named sprite, you can make a new copy of that sprite by "duplicating" it.
Sprite newsprite = MySpriteController.DuplicateSprite(“shot”);
//We figure out where to put the shot
Point where = Spaceship.PictureBoxLocation;
int halfwit = Spaceship.VisibleWidth / 2;
halfwit = halfwit - (newsprite.VisibleWidth / 2);
int halfhit = newsprite.VisibleHeight / 2;
where = new Point(where.X + halfwit, where.Y - halfhit);
newsprite.PutPictureBoxLocation(where);
//We tell the sprite to automatically move
newsprite.AutomaticallyMoves = true;
//We give it a direction, up
newsprite.SetSpriteDirectionDegrees(90);
//we give it a speed for how fast it moves.
newsprite.MovementSpeed = 20;
Each of these duplicates has their own location, direction, speed, and the like. When you duplicate a sprite, none of those properties are copied. You need to manually set those. A duplicated sprite only retains the original images (animations), any events you have set, and the animation speeds for each animation.
The SpriteDatabase
A SpriteDatabase is another way to define named sprites. If your program only has a few Sprites, than using a database may be a bit of overkill. But if you have a lot of sprites, or you are using multiple PictuerBoxes, you may want to consider setting up a SpriteDatabase.
The database allows you to build a file that defines all your sprites. If you instantiate your SpriteController with the Database, or you add it using SetSpriteDatabase, the SpriteController will reference the database when you asked for a named sprite. The nice thing about this, is that it spreads out the creation of sprites. In the AdventureDemo example, it took four or five seconds for the game to start while the SpriteController was creating the initial sprites. If a Database was used, the sprites would only be created when first referenced, which means that the load-time is virtually un-noticeable.
The SpriteDatabase has the additional benefit of letting you define your sprites through a GUI. The OpenEditWindow function will allow you to browse through the images which you have already added as resources to your project. You can highlight an item to turn into a sprite, specify the number of frames, and even preview the sprite.
Resources are read-only, so you use this function by instantiating the database by giving it a filename. Then you use the OpenEditWindow function of the database. When you are done defining your sprites, you can add the file as a resource to your program, and then instantiate the database using the resource name instead of the filename.
Once you have sprites defined in the database, any SpriteController that knows about the database will be able to return those sprites. For example, if we have a sprite named “Power Station” defined in the SpriteController, we can do a:
Sprite newsprite = MySpriteController.DuplicateSprite(“Power Station”);
And we will get a sprite back. The SpriteController will look up the sprite definition and create a named sprite based off of that template, and then it will return a copy of that named sprite for your use.
You do not need to both link SpriteControllers and use a SpriteDatabase, you should either do one or the other. If you want to use the sprite definition system of the SpriteDatabase, then do not bother with linking SpriteControllers. If you prefer to manually define your named Sprites, then do not bother with a SpriteDatabase.
#Linked SpriteControllers Another way to share sprite templates between SpriteControllers is by linking SpriteControllers using the LinkControllersForSpriteTemplateSharing function. Once your Controllers have been instantiated, you can link them to each-other. You only need to link them one way; they are automatically linked bi-directionally. If you need to destroy one of the controllers, be sure to unlink them first. You can have some very odd behavior if you do not.
What linked SpriteControllers do, is that a named Sprite can be accessed from either controller. The primary reason to do this, is to make it so you do not need to load lots and lots of the same sprites for multiple controllers.
One place where this would have been useful was in the AdvDemo program, where there was a playing-field that you ran around on, and a battle Picture-box where the sprites were seen much larger. That program had a lot of sprites, and took a long time to load them. It would take twice as long, if I chose to load the sprites into both of them. By linking the controllers, it would allow me to define the sprites once, but access them in multiple controllers. You do not need to both link SpriteControllers and use a SpriteDatabase, you should either do one or the other. If you want to use the sprite definition system of the SpriteDatabase, then do not bother with linking SpriteControllers. If you prefer to manually define your named Sprites, then do not bother with a SpriteDatabase.