Frage

Ich entwickle ein XNA-Spiel.Dies ist der Zeitpunkt, an dem ich auf die Architektur achte.Bis heute habe ich meine eigene Zeichenmethode immer auf diese Weise implementiert:

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

Ich habe nach DrawableGameComponent gesucht und festgestellt, dass die Draw-Methode folgendermaßen funktioniert:

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

Zunächst einmal weiß ich, dass SpriteBatch viele Texture2D zwischen Anfang und Ende sammeln kann, sodass es nützlich sein kann, sie zu sortieren oder mit denselben Effekten zu zeichnen.

Meine Frage betrifft die Leistung und die Kosten für die Weitergabe des SpriteBatch.Bei DrawableGameComponent ist es möglich, Spritebatch eines Spielobjekts aufzurufen, wenn sein Spritebatch öffentlich ist.

Was wird empfohlen, was sollte ein XNA-Game-Programmierer tun?

Vielen Dank für den Rat.

War es hilfreich?

Lösung

Einer der gravierenden Nachteile von DrawableGameComponent ist, dass Sie an die bereitgestellte Methodensignatur gebunden sind.Es gibt zwar per se nichts „falsches“ mit DrawableGameComponent, Betrachten Sie es nicht als „eine wahre Architektur".Du bist besser dran Betrachten Sie es als Beispiel für eine Möglichkeit die Architektur.

Wenn Sie feststellen, dass Sie eine bestehen müssen SpriteBatch (oder irgendetwas anderes) zur Zeichenmethode einer „Spielkomponente“ - der beste Weg Ist um es als Argument weiterzugeben.Alles andere ist kompliziert.

Dies bedeutet natürlich, dass Sie die bereitgestellten XNAs nicht verwenden können GameComponent System, und Sie müssen Ihre eigene Alternative finden.Aber das ist fast trivial:Auf der grundlegendsten Ebene handelt es sich lediglich um eine Liste einiger Basistypen, die über entsprechende virtuelle Methoden verfügen.


Natürlich, wenn Sie es verwenden müssen GameComponent - oder Ihr Spiel ist so einfach (z. B.:ein Prototyp), dessen Architektur Ihnen eigentlich egal ist – dann können Sie es grundsätzlich nutzen beliebig Methode, die Sie gerne erhalten möchten SpriteBatch zu Ihrer Zeichenmethode.Sie alle haben Nachteile.

Die wahrscheinlich zweitstärkste architektonisch robuste Methode besteht darin, Ihr zu übergeben SpriteBatch Instanz in den Konstruktor jeder Ihrer Komponenten.Dadurch bleiben Ihre Komponenten von Ihrer Spielklasse entkoppelt.

Wenn Sie andererseits Architektur in den Wind werfen, würde ich vorschlagen, Ihre eigene zu machen MyGame.spriteBatch Feld public static.Dies ist die einfachste Möglichkeit, den Zugriff überall zu ermöglichen.Es ist einfach zu implementieren und später bei Bedarf leicht zu bereinigen.


Um Ihre Frage zur Leistung zu beantworten:Alles, was mit dem Bestehen eines zu tun hat SpriteBatch herum wird fast vernachlässigbare Auswirkungen auf die Leistung haben (die Reihenfolge der Aufrufe festlegen). Draw/Begin/End bleibt gleich).Machen Sie sich darüber keine Sorgen.

(Wenn du siehst SpriteBatch whatever im Code stellt das eine Referenz dar.Eine Referenz ist ein 32-Bit-Wert (in einem 32-Bit-Programm, das alle XNA-Spiele sind).Das ist die gleiche Größe wie ein int oder ein float.Es ist sehr klein und sehr günstig in der Weitergabe/Zugang/usw.)

Andere Tipps

Wenn Sie auf diese Frage stolpert, haben Sie wahrscheinlich eine schöne und generische Lösung angesehen.Ich würde vorschlagen, dass Sie Folgendes ansehen:

https://gamedev.steckexchange.com/questions/14217/Sveral-Classes-Need-No-Access-the-Same-Data-Wahrscheinlich-Die-Das-Daten-Daten-Daten-Daten-Daten-Daten-Daten-Daten-Daten-harte/14232#14232

0/ p>

Ich persönlich tue es jetzt auf diese Weise in meiner GameBase-Klasse:

generasacodicetagpre.

jetzt, da Sie in der Initialisierungsmethode Ihrer Spielklasse Zeichnungsdamenkomponenten hinzufügen, können Sie in der Lage sein,

anzurufen. generasacodicetagpre.

Ich würde sagen, das ist der sauberste Ansatz, um das Problem zu lösen.

Wenn die DrawableGameComponent sollte Teil der Eltern sein SpriteBatch, dann übergeben Sie es einfach über den Konstruktor und speichern Sie es in einem privaten Member (oder machen Sie es als Eigenschaft verfügbar, wenn Sie möchten).

Sie könnten das auch offenlegen SpriteBatch als Eigentum von Ihnen Game Klasse, wenn Sie wollten, wie Sie vorgeschlagen haben, aber jedes Mal, wenn Sie darauf verwiesen haben this.Game, müssten Sie es auf Ihre spezifischen Bedürfnisse umstellen Game Klassentyp.

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

Oder Sie können einfach das haben DrawableGameComponent erstelle eine neue SpriteBatch.Daran ist nichts auszusetzen (soweit ich das jemals gesehen habe).Ich nehme an, es kommt darauf an, wie viele DrawableGameComponentWas werden Sie erstellen und wie oft?

Durchsuchen Sie auch die Ergebnisse nach a suchen nach DrawableGameComponent - Da gibt es viele gute Ratschläge.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top