问题
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.
回答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.)
回答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.
回答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 DrawableGameComponent
s 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.
来源:https://stackoverflow.com/questions/12714720/xna-draw-using-one-spritebatch-at-whole-game