XNA Inheritence via Texture2D

Question

As you know to draw a Texture2D mostly an Origin, scale-factor, rotation-value and color is necessary.

To inherite a new class ATexture2D from Texture2D with adding this parameters, can cause performance problems if many of them are called ?

Or what is prefered to do it in this case.

I ask this question for 2D games, where many texture2D objects are used, updated and drawn.

Answer 1

There's pretty much only one reason you can't reasonably do this, and that is that you generally get your textures from either Content.Load<Texture2D> or Texture2D.FromStream.

Both of these methods return Texture2D. To get a child class involves either an expensive copy operation, or overcomplicated changes to the content pipeline to get it to return your child class instead.

If this were not the case, then a child class wouldn't be unreasonable. Object composition (as suggested in both Roy T and Blau's answers) is a good alternative.

In fact, object composition can be better. It allows you to share a single texture between many sprite objects (something you can't do easily with inheritance). This is useful for, for example, having different sprite objects refer to individual sprites that are on a single texture atlas.

---

Although, in the majority of cases you will find that you have either:

• Standard defaults: scale of 1, a rotation of 0, a colour of White, and an origin at some fixed point, like the top left (Vector2.Zero) or centre (new Vector2(tex.Width/2, tex.Height/2))
• Code-derived values. For example: you might animate the rotation of your player sprite, or the scale and opacity of an explosion sprite. (Or have a fixed colour per-team, for example.)

Or some combination of the above two. And in these cases you should pass either the constant or the result of your animation calculation directly to SpriteBatch.Draw.

It's quite unusual to have many different, fixed-per-sprite values for rotation, scale and colour. A better argument could be made for storing per-sprite source-rectangle and origin, though (useful for a texture atlas).

Answer 2

You will need to store scale, translation and rotation somewhere so memory wise there isn't really a penalty by inheriting from Texture2D and adding this data. I think performance wise the same applies although you do add some extra look ups for methods.

However I would suggest using composition in this case because that makes more sense.

class Sprite
{
    Texture2D myTexture;
    Vector2 myPosition;
    float myScale;
    float myTranslation;

    void Draw(); { ... }
}

The benefit of this is that you keep your type hyarchy shallower, and conceptualy it makes more sense because adding information on how to draw a texture does not make something a specialization of a texture for which (conceptually) inheritance is intended.

Answer 3

You dont need to inherite from texture2D... I think you are describing a sprite class...

 class Sprite 
 {
      Texture2D Texture;
      Vector2 Position;
      float Scale;
      float Rotation;
      ....
 }

Later you can use this class as base for other components like AnimatedSprite, Enemy, Player, Background, ...

Usually there is no problem with having many sprite objects... but is known that changing too many times the drawed texture can cause a penalty... but is easily solved ordering by texture with SpriteSortMode.Texture in your spritebatch.Begin() method or using testures atlas to avoid using too many textures.

http://msdn.microsoft.com/es-ES/library/microsoft.xna.framework.graphics.spritesortmode(v=xnagamestudio.40).aspx