There's pretty much only one reason you can't reasonably do this, and that is that you generally get your textures from either
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
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).