Bump/Normal Mapping und Shader-Performance verstehen

Der Herr der Hügel (Teil 3)
Kommentare

Windows Developer

Der Artikel „Der Herr der Hügel“ von Tam Hanna ist erstmalig erschienen im Windows Developer 7.2012
Stoppuhr und Mittelwert
Die im Beispiel auf der CD zur Ermittlung der Frame-Rate

Windows Developer

Der Artikel „Der Herr der Hügel“ von Tam Hanna ist erstmalig erschienen im Windows Developer 7.2012

Stoppuhr und Mittelwert

Die im Beispiel auf der CD zur Ermittlung der Frame-Rate herangezogene Methode ist in der Tat etwas seltsam. Daher wollen wir sie uns etwas näher ansehen. Die eigentliche Intelligenz befindet sich dabei in der Draw-Routine. Abgekürzt sieht sie in etwa wie in Listing 5 aus.

Listing 5

protected override void Draw(GameTime gameTime)
{
            myStopwatch.Start();
            GraphicsDevice.Clear(Color.CornflowerBlue);
            . . .

            myStopwatch.Stop();
            usedMillis = myStopwatch.ElapsedTicks;
            myStopwatch.Reset();
}  

Will man auf der Xbox 360 Timing-Aufgaben erledigen, schlägt die Stunde der StopWatch-Klasse. Sie ist an sich relativ primitiv: Nach dem Aufrufen der Methode Start() zählt sie die ablaufende Zeit. Ruft man Stop() auf, hört die Zählung auf. Die Werte können in Ticks, Millisekunden oder Sekunden zurückgegeben werden. Da manche Systeme bis zu zwei Millionen Ticks pro Sekunde abfeuern, ist die erreichbare Genauigkeit enorm. Die Methode Frequency gibt in diesem Fall Auskunft über die Tickfrequenz.

Übrigens: Da unser Code ausschließlich die in der Methode Draw() verbrachte Zeit berechnet, liefert er natürlich keine hundertprozentig echten Frame Raten. Die für Housekeeping, Garbage Collection, Polling der Eingabegeräte etc. verwendete Zeit ist in den weiter oben abgedruckten Zahlen nicht angegeben. Allerdings: Das Beheben dieses Zustands ist nur eine Frage des „Replatzierens“ der Stop()– bzw. Reset()-Anweisung der StopWatch-Instanz. Die Stopwatch-Klasse sitzt übrigens im Namespace System.Diagnostics. Bei der erstmaligen Verwendung sollte man sie so deklarieren, um IntelliSense ein wenig auf die Sprünge zu helfen:

System.Diagnostics.Stopwatch myStopwatch = new System.Diagnostics.Stopwatch();  

Interessant ist unter Umständen auch die Methode der Ermittlung der Frame-Rate (Listing 6). Da die zum Rendering benötigte Zeit allerdings stark schwankt, ist eine „Beruhigung“ wünschenswert, und so etwas geht nun mal am besten über diese Methode. In fpsArray errichten wir mit der Variable fpsPointer einen Ringspeicher, der immer die letzten 50 fps-Werte vorhält. Um die eigentliche Frame-Rate zu ermitteln, addieren wir die im Array gespeicherten Werte und dividieren sie durch 50. Dadurch sparen wir uns die eine oder andere Division.

Listing 6

double fps = 0;
fpsArray[fpsPointer] = Stopwatch.Frequency / usedMillis;
fpsPointer = fpsPointer + 1;
if (fpsPointer == 50) fpsPointer = 0;
for (int i = 0; i < 49; i++)
    fps += fpsArray[i];
fps = fps / 50;  
Ein SpriteBatch im Pfeffer

Das Darstellen der Texte erfolgt mittels SpriteBatch und SpriteFont. Wir haben diese Klassen schon in der Vergangenheit verwendet und erklärt. Interessant ist diesmal nur die andere Art des Aufrufs der Begin-Methode:

spriteBatch.Begin(SpriteSortMode.FrontToBack,BlendState.Opaque);  

Der Grund dafür liegt in der Art der Realisierung von SpriteBatch. Um ihre Aktivitäten möglichst effizient erledigen zu können, passt die Klasse nämlich den Zustand des Rendering Device an. Die möglicherweise betroffenen Attribute sind im unter [1] erhältlichen, etwas veralteten Artikel aufgelistet. Berücksichtigt man dies nicht, sehen durch Shader errechnete Grafiken unter Umständen wie in Abbildung 11 gezeigt aus. Funktionieren die Shader einer Anwendung einmal nicht, ist SpriteBatch häufig ein Schuldiger.

Abb. 11: Die Transparenz funktioniert nicht, da SpriteBatch die Einstellungen ändert
Abb. 11: Die Transparenz funktioniert nicht, da SpriteBatch die Einstellungen ändert

Übrigens: In der MSDN findet man oft Hinweise auf eine RestoreState-Funktion von SpriteBatch. Diese ist leider nur unter XNA 3.1 verfügbar und wurde in XNA 4.0 entfernt. Microsoft begründete dies damit, dass das permanente Sichern und Laden des Render-Zustands zu massiven Performanceeinbrüchen führt.

Screenshots herbei

Die in diesem Artikel abgedruckten Screenshots zeigen das Benchmark-Programm, während es auf einer realen Xbox 360 ausgeführt wird. Sie entstanden nicht durch Fotografieren des Bildschirms. Ab Version 4.0 von XNA gibt es nämlich eine ins SDK integrierte Screenshot-Funktion. Dazu startet man das im Debug-Modus kompilierte Programm über Visual Studio und startet mit dem Startmenü während der laufenden Debugging-Sitzung das aus Teil 1 der Serie bekannte XNA Game Studio Device Center. Danach klickt man die im Moment aktive Xbox 360 rechts an und wählt die Option TAKE SCREENSHOT. Die IDE transferiert daraufhin den Screenshot auf die Workstation. Der Prozess dauert rund eine Sekunde, danach erscheint der Screenshot in der Bildergalerie. Unter Vista und Windows 7 liegen die Bilder danach im Pictures-Verzeichnis. Ist man beispielsweise als TAMHAN eingeloggt, wäre das Verzeichnis C:UsersTAMHANPictures.

Fazit

Die Welt der dreidimensionalen Programmierung ist und bleibt faszinierend. Obwohl wir uns nun vier Artikel lang ausschließlich mit Shadern befasst haben, haben wir noch nicht einmal ein Hundertstel der mit dieser Programmiermethode möglichen Darstellungsformen gesehen. Doch damit vorerst einmal genug. Schöne Grafik genügt in der Regel nämlich nicht, um ein Spiel zu einem Bestseller zu machen. Ist die Spielidee mangelhaft, der Tiefgang minimal und die Steuerung unsinnig realisiert, sind die Spieler trotzdem unzufrieden. Das Einführen einer Mehrspielerkomponente kann aus absolut langweiligen Spielideen richtige "Partykracher" machen. Wenn es dann noch möglich ist, über das Internet zu spielen - Ja, dann sind die Topscores der Analysten schon fast sicher. Ab dem nächsten Teil der Serie begeben wir uns daher in diese Welt der Mehrspielerei. Man liest sich!

Tam Hanna befasst sich seit der Zeit des Palm IIIc mit Programmierung und Anwendung von Handcomputern. Er entwickelt Programme für diverse Plattformen, betreibt Onlinenewsdienste zum Thema und steht unter tamhan@tamoggemon.com für Fragen, Trainings und Vorträge gern zur Verfügung.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -