XNA draw : using one spritebatch at whole game

Question

I am developing an XNA game. This is time I am careful about the architecture. Til today, I have always implemented my own draw method in this way:

public void Draw(SpriteBatch sb, GameTime gameTime)
{
    sb.Begin();
    // ... to draw ...
    sb.End();
}

I was digging the DrawableGameComponent and saw the Draw method comes in this way:

public void Draw(GameTime gameTime)
{
    // ...
}

First of all, I know that SpriteBatch can collect many Texture2D between Begin and End, so that it can be useful to sort them, or draw with same Effects.

My question is about the performance and the cost of passing the SpriteBatch. At DrawableGameComponent it is possible to call spritebatch of game object if its spritebatch is public.

What is suggested, what should a xna-game programmer do?

Thanks in advice.

Answer 1

One of the serious disadvantages of DrawableGameComponent is that you're locked into its provided method signature. While there's nothing "wrong", per se, with DrawableGameComponent, do not think of it as the "one true architecture". You're better off thinking of it as an example of a possible architecture.

If you find yourself needing to pass a SpriteBatch (or anything else) to the draw method of a "game component" - the best way is to pass it as an argument. Anything else is convoluted.

Obviously this means that you can't use XNA's provided GameComponent system, and you have to make your own alternative. But this is almost trivial: At its most basic level, it's just a list of some base type that has appropriate virtual methods.

---

Of course, if you must use GameComponent - or your game is so simple (eg: a prototype) that you don't really care about the architecture - then you can use basically any method you like to get a SpriteBatch to your draw method. They all have disadvantages.

Probably the next-most architecturally robust method is to pass your SpriteBatch instance into the constructor of each of your components. This keeps your components decoupled from your game class.

On the other hand, if you're throwing architecture to the wind, I'd suggest making your MyGame.spriteBatch field public static. This is the simplest way to allow it to be accessed anywhere. It's easy to implement and easy to clean up later when/if you need to.

---

To answer your question about performance: Anything to do with passing a SpriteBatch around will have almost negligible effect on performance (providing the order of calls to Draw/Begin/End stays the same). Don't worry about it.

(If you see SpriteBatch whatever in code, that represents a reference. A reference is a 32-bit value (in a 32-bit program, which all XNA games are). That's the same size as an int or a float. It's very small and very cheap to pass around/access/etc.)

Answer 2

If you stumbled upon this question you were probably looking at a nice and generic solution. I would suggest you have a look at this:

https://gamedev.stackexchange.com/questions/14217/several-classes-need-to-access-the-same-data-where-should-the-data-be-declared/14232#14232

I felt the need to correct this question because "the best way is to pass it as an argument. Anything else is convoluted." is simply not correct.

Personally i am now doing it this way in my GameBase class:

    protected override void LoadContent()
    {
        // Create a new SpriteBatch, which can be used to draw textures.
        SpriteBatch = new SpriteBatch(GraphicsDevice);
        this.Services.AddService(typeof(SpriteBatch), SpriteBatch);
    }

Now, since you're adding DrawableGameComponents in the Initialize Method of your Game class you will be able to call

    this.Game.Services.GetService(typeof(SpriteBatch))

I'd say that's the cleanest approach to solve the problem.

Answer 3

If the DrawableGameComponent should be part of the parent's SpriteBatch, then just pass it in via the constructor and store it in a private member (or expose it as a property if you wish).

You could also expose the SpriteBatch as a property of your Game class if you wanted, like you suggested, but every time you referenced this.Game, you would need to cast it to your specific Game class type.

((MyGame)this.Game).SpriteBatch.Draw(...)

Or you can just have the DrawableGameComponent create a new SpriteBatch. There's nothing wrong with that (as far as I've ever seen). I suppose it depends how many DrawableGameComponents you'll be creating and how often.

Also browse through the results for a search for DrawableGameComponent - there's a lot of good advice there.