public ASprite(string path, Vector2? loc = null)
{
pos = loc ?? Vector2.Zero;
image = content.Load<Texture2D>("Graphics/" + path);
}
If you're baffled by what is going on, I don't blame you. It certainly looks quite funky, so let me explain what we're trying to do.
When the user wants to create a new sprite, they must provide the path name to the Texture2D resource they want to use, and they may also provide the Vector2 position of their sprite. C# takes in optional arguments by specifying their default values in the parameters (for example, method(int x, int y = 5) requires an int for x, and an optional value for y that defaults to 5 when unspecified).
The question mark after the Vector2 specifies the value we're taking in is nullable. A nullable type is like it's original type, but that it's range of values can also acceptably include null. In our case, we're saying that if the developer does not specify the optional value for our vector2, it will default to null.
Inside the constructor, the first line uses a special operator (??) that sets pos equal to loc if it has a value (is not null), or otherwise sets it to the value of Vector2.Zero (0.0, 0.0). This ensures that if the developer specified a starting Vector2, it's position is set. Otherwise, if it's not set, or set to null, it defaults to the top-left corner (0.0, 0.0).
If you're paying attention, you might be thinking, "Why don't we just say (... Vector2 loc = Vector2.Zero) and avoid the nullable thing all together?"
The problem here is rather asinine; to specify optional parameters you need compile-time constants (nothing that requires extra computation to determine). This means you can't specify it as (... Vector2 loc = new Vector2(0.0, 0.0) ) either.
Wow. That's a lot of explanation for a simple constructor. Lets finish this bad boy up. All we need now is just a draw method. As it should, it will take our spriteBatch and use that to draw our sprites.
public void Draw(SpriteBatch sb)
{
sb.Draw(image, pos, src_rect, blend_color, angle, origin, scale, effect, z);
class Sprite : ASprite
{
public Sprite(string path, Vector2? v = null) : base(path, v)
{
}
public new void Draw(SpriteBatch s_Batch)
{
base.Draw(s_Batch);
}
}
The Sprite class now extends ASprite, and holds all it's properties and methods. These members can be overwritten with the new keyword (as we did with the Draw method) and the inherited members can be called with the base keyword.
To draw a new image, in the SCENE.Update(), just create a new instance of Sprite. initiate and tweak your Sprite instances as you see fit (Sprite.Rotation = 45). They can be easily rotated, flipped, and moved. There just simply needs to be a call somewhere in the SCENE.Draw() to actually draw the sprite.
Not shabby at all?
So why did we want to make an abstract class in the first place? After all, having only one class to shape after an abstract class is kinda pointless. Unless of course, we want to create more classes that would extend our abstract class. Such as a class to cut the image into pieces and draw only one piece at a time. Like, say for example, in a sprite sheet...
Homework: Opacity in XNA images is calculated strangely. You would think it would be derived by the Alpha value used in the blending color, but it is in fact much different. Alpha values are imparted onto drawn graphics by multiplying a float value to the blending color, with 0.0f being full transparency, and 1.0f being fully opaque. So to draw an image at 50% opacity, you would blend with blend_color * 0.5f .
Create one extra public integer value for Sprite called Opacity. When the developer changes the value of opacity (from 0-255), change the draw method so the image blends with the set opacity.
Wow. That's a lot of explanation for a simple constructor. Lets finish this bad boy up. All we need now is just a draw method. As it should, it will take our spriteBatch and use that to draw our sprites.
public void Draw(SpriteBatch sb)
{
sb.Draw(image, pos, src_rect, blend_color, angle, origin, scale, effect, z);
}
That's a lot of parameter's, innit?
Now, we just need to make an actual Sprite Class that we can make instances of. In a separate class, add the following code:class Sprite : ASprite
{
public Sprite(string path, Vector2? v = null) : base(path, v)
{
}
public new void Draw(SpriteBatch s_Batch)
{
base.Draw(s_Batch);
}
}
The Sprite class now extends ASprite, and holds all it's properties and methods. These members can be overwritten with the new keyword (as we did with the Draw method) and the inherited members can be called with the base keyword.
To draw a new image, in the SCENE.Update(), just create a new instance of Sprite. initiate and tweak your Sprite instances as you see fit (Sprite.Rotation = 45). They can be easily rotated, flipped, and moved. There just simply needs to be a call somewhere in the SCENE.Draw() to actually draw the sprite.
Not shabby at all?
So why did we want to make an abstract class in the first place? After all, having only one class to shape after an abstract class is kinda pointless. Unless of course, we want to create more classes that would extend our abstract class. Such as a class to cut the image into pieces and draw only one piece at a time. Like, say for example, in a sprite sheet...
Slots animation by Mia. Unsure of how to link to her work, but this sprite sheet serves a good example of what we will be tackling.
Homework: Opacity in XNA images is calculated strangely. You would think it would be derived by the Alpha value used in the blending color, but it is in fact much different. Alpha values are imparted onto drawn graphics by multiplying a float value to the blending color, with 0.0f being full transparency, and 1.0f being fully opaque. So to draw an image at 50% opacity, you would blend with blend_color * 0.5f .
Create one extra public integer value for Sprite called Opacity. When the developer changes the value of opacity (from 0-255), change the draw method so the image blends with the set opacity.
