XNA抽奖:在整个游戏中使用一个spritebatch [英] XNA draw : using one spritebatch at whole game

问题描述

我正在开发XNA游戏.这是我要谨慎对待体系结构的时候了.直到今天，我一直以这种方式实现自己的绘制方法:

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();
}

我正在挖掘DrawableGameComponent，并看到Draw方法是通过这种方式来实现的:

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

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

首先，我知道SpriteBatch可以在Begin(开始)和End(结束)之间收集许多Texture2D，以便对它们进行排序或使用相同的Effects进行绘制很有用.

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.

我的问题是关于通过SpriteBatch的性能和成本.在DrawableGameComponent上，如果其spritebatch是公共的，则可以调用游戏对象的spritebatch.

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.

有什么建议，xna游戏程序员应该怎么做?

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

感谢您的咨询.

推荐答案

DrawableGameComponent的严重缺点之一是您被锁定在其提供的方法签名中.虽然在DrawableGameComponent本身没有什么错误"，但不要将其视为"一个真正的体系结构".您更好将其视为可能的

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.

如果您发现自己需要将SpriteBatch(或其他任何东西)传递给游戏组件"的draw方法- 的最佳方法是将其作为参数传递.其他的一切都令人费解.

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.

显然，这意味着您不能使用XNA提供的GameComponent系统，而您必须自行选择.但这几乎是微不足道的:从最基本的角度讲，它只是具有适当虚拟方法的某些基本类型的列表.

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.

当然，如果您必须使用GameComponent-或者您的游戏是如此简单(例如:原型)，以至于您并不真正在乎架构-那么您基本上可以使用 any 您想为draw方法获取SpriteBatch的方法.它们都有缺点.

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.

在结构上最可靠的方法可能是将SpriteBatch实例传递到每个组件的构造函数中.这样可以使您的组件与游戏类脱钩.

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.

另一方面，如果您对体系结构不满意，建议将您的MyGame.spriteBatch字段设置为public static.这是允许在任何地方访问它的最简单方法.它很容易实现，以后也可以在需要时清理.

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.

要回答有关性能的问题:与传递SpriteBatch有关的所有操作对性能的影响几乎可以忽略不计(假设对Draw/Begin/End的调用顺序保持不变).不用担心.

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.

(如果在代码中看到SpriteBatch whatever，则表示一个引用.引用是一个32位值(在32位程序中，所有XNA游戏都为该值).它的大小与int或float.它很小，可以很方便地传递/访问/等.

(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.)

这篇关于XNA抽奖:在整个游戏中使用一个spritebatch的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！