Getting Started
IMPORTANT
If you're having trouble, be sure to see the Troubleshooting section, as well as the relevant topic pages. If you still have an unresolved issue, be sure to visit the forum at forum.anbsoft.com.
Installation
|
Basic Setup
It is important to understand that SpriteManager 2 offers two different kinds of sprites (PackedSprite and ManualSprite) depending on what functionality you need. We will look at step-by-step instructions for setting up each kind:
PackedSprite The PackedSprite class is the more feature-rich of the two types of Sprites and probably the easiest to use. It is particularly useful for people who do not want to have to layout their own texture atlases ahead of time or who want to make the most of their texture memory by using non-uniform sprite animations. The PackedSprite class allows you to specify animations by dragging and dropping individual textures which, by themselves, constitute a single frame of sprite animation. Then, as a separate step, you compile your sprite atlas(es) and each of these separate textures will be combined into a single texture without duplication. Let's see how this works, step-by-step:
ManualSprite The ManualSprite class works in a similar fashion to the original SpriteManager sprites. Animations consist of a series of uniformly-sized sprite frames. This class is useful if you want to use pre-made sprite atlases and do not want to use the new atlas generation feature. To setup a ManualSprite component, follow these steps:
|
Playing Animations
There are several ways to play animations on a sprite. You can play them by name, by index, or by reference. The fastest method is by reference, and a close second is by index. However, most of the examples you will find in this documentation will use the name method because it is easier to read and simpler to understand. There are two main method categories which will play an animation: PlayAnim() and DoAnim(). The difference between these two is that PlayAnim(), anytime it is called, will re-start the animation at the first frame (or frame specified). DoAnim(), on the other hand, will only start an animation if that same animation is not already running. It is therefore a good idea to use DoAnim() in places where you just know that a certain animation ought to be running if it isn't already but don't want to have to check first. Use PlayAnim() in places where you know the animation should always start over, or start from a particular frame. Both PlayAnim() and DoAnim() have versions which accept the animation's name, index, or reference as arguments. Some examples of these are shown below ("sprite" in the code below, is assumed to reference a ManualSprite or PackedSprite script). // Play "walk" animation:
In addition to these, the PackedSprite class also has versions of each which also accept an additional frame number argument. This second argument is the 0-based index of the desired frame on which the animation should start playing. Some examples: NOTE: These versions are only available on PackedSprites // Play "walk" animation, starting at frame 3:
Stopping and Pausing You may also stop and pause playback of an animation using the StopAnim() and PauseAnim() methods, and can unpause using UnpauseAnim(): // Pause playback of the current animation:
Posing You may have a sprite that instead of, or in addition to, using animation, it uses a series of "poses" depending on its state. An example would be an overhead view of an airplane that shows the airplane at various angles of banking depending on how steep the player is turning. For situations like this, you wouldn't want to play an animation but you can't get by with only one static frame either. In this situation you can use multiple, single-frame animations and simply "play" each animation that is needed for the particular pose. This will effectively change the frame being displayed. Alternatively, you can store the entire range of "poses" in a single animation, and simply play the animation starting at a specific frame, and then immediately pause the animation, like so: // Frame 4 contains our desired "pose":
|
Additional Notes
Making Changes Always remember, whenever you make changes to a sprite, such as changing its static texture or the frames in its animations (including deleting them), you must rebuild your atlases for the changes to take effect. IMPORTANT NOTE: If your game consists of more than one scene that contain identical sprites, or you have any prefabs with sprites, it is recommended that every sprite you create be associated with a prefab, and then as you make design changes to your sprites (such as changing their textures), only make these changes to the prefabs directly and let the instances of those prefabs in your scene(s) be automatically updated. Making changes directly to sprites in a scene which are linked to a prefab will cause the properties you change to "override" the same properties in the prefab. The problem with this is that the atlas builder will skip prefab instances and only look at the "source" prefab, meaning a prefab instance that has a different set of textures than its original prefab will not get updated with the correct UVs and will not have its differing source textures included on the atlas. This is by design so that sprites in a non-open scene do not get "left behind" when a new atlas is generated. The rule of thumb is to manage and keep all your sprite types in prefabs and only modify the properties of the prefabs themselves and not the prefab instances in a scene.
|