Du bist nicht angemeldet.

Werbeanzeige

1

27.09.2015, 22:46

Performance-Verbesserung beim programmierten Spiel C++

Hallo Forum!

beim Programmieren an meinem neuen Spiel habe ich festgestellt, dass manche große Funktionen die FPS deutlich sinken lassen (120 FPS auf 95).

Nun lasse ich diese Funktionen einfach nicht bei jedem Programmdurchlauf berechnen, sondern beispielsweise nur bei jedem Dritten.
Die FPS gehen dadurch wieder hoch, nun ist meine Frage ob das Spiel dadurch "ungleichmäßig" wird/ruckelig, da bei manchen Programmdurchgängen mehr gerechnet weren muss, als bei anderen (bei mir am PC konnte ich nichts feststellen, aber bei schwächeren PC's?).

Ist es grundsätzlich überhaupt eine gute Idee nicht das komplette Programm jedes mal rechnen zu lassen?
Und wenn ja, wie kann abgeschätzt/gemessen werden, wie viel Rechenzeit eine Funktion in Anspruch nimmt. Sonst könnte man ja einfach unterschiedliche Funktionsblöcke zusammenfassen, die jeweils etwa die gleiche Rechenzeit benötigen...

Was sind andere bewährte Techniken? (Außer effizientere Funktionen ausdenken :))

Schönen Abend!

2

27.09.2015, 23:43

Multithreading. :)

MfG
Check

H5::

Treue Seele

Beiträge: 385

Wohnort: Kiel

  • Private Nachricht senden

3

28.09.2015, 00:17

Nur als Anmerkung, FPS sind nicht unbedingt gut dazu geeignet Laufzeitveränderungen zu analysieren.

fps versus frame time
:love: := Go;

xardias

Community-Fossil

Beiträge: 2 771

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

4

28.09.2015, 00:42

Profiling ist ein weiteres hilfreiches Stichwort. Ein profiler analysiert waerend dein Programm laeuft, wie viel Zeit in welcher Funktion drauf geht.

Du koenntest natuerlich auch einfach selbst messen indem du die Zeit vor und nach dem ausfuehren deiner Funktion vergleichst.

JaielSoft

Alter Hase

Beiträge: 1 164

Wohnort: Berlin

Beruf: Student Ang. Informatik

  • Private Nachricht senden

5

28.09.2015, 09:52

Also meistens sind die Renderzugriffe der Flaschenhals bei Spielen. Kann mir jetzt nur spezielle Situationen vorstellen wo alleine von vielen Methodenaufrufen das Programm performancemäßig darunter leidet(Zum Beispiel Kollisionsberechnungen mit vielen Objekten wie bei Partikeleffekten zum Beispiel).

Generell musst du eh bei jedem Frame deine Objekte auf dem Schirm berechnen bevor es zum Rendern geht, da hilft auch kein Multithreading.

Was für Berechnungen führst du denn durch wenn ich fragen darf die du mal einfachso auslagern kannst nach belieben?

6

28.09.2015, 10:47

@JaielSoft:

Im speziellen sind das zwei Funktionen, einmal das Anklicken/Markieren von Objekten (Einheiten, Gebäude, aber auch Schaltflächen) und zum weiteren die Aktualisierung der "Minimap"/Übersichtskarte.

Ersteres muss von mir einfach noch wesentlich verbessert werden, da schicke ich noch zu viele Zeiger hin und her.... Aber bei der Minimap fällt es nicht auf, wenn das eine Pixel minimal später ein Pixel weiter läuft.

@xardias:

Danke, werde den Begriff mal googeln :)

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

7

30.09.2015, 11:14

Generell musst du eh bei jedem Frame deine Objekte auf dem Schirm berechnen bevor es zum Rendern geht, da hilft auch kein Multithreading.


Wie meinst du das? Inwiefern sollten Multithreading-Ansätze da nicht helfen können? Je nach Situation lassen sich solche "Berechnungen" häufig gut auf verschiedene Prozessorkerne verteilen. Auch beim Aufbauen eines Frames kann ein MT getriebenes System (z.B. ein Taskgraph) deutlich die CPU Performanz verbessern. Generell sollte Parod0ntos3 natürlich erstmal die Bottlenecks identifizieren bevor überhaupt irgendwelche Tipps bzgl Optimierung gegeben werden können.
@D13_Dreinig

JaielSoft

Alter Hase

Beiträge: 1 164

Wohnort: Berlin

Beruf: Student Ang. Informatik

  • Private Nachricht senden

8

30.09.2015, 11:29

nur weil man multithreading betreibt heißt es nciht dass diese Threads dann auf verschiedenen Kernen laufen
da händelt die CPU alles ganz anders als du dir das wünscht. Alle Prozesse müssen eh fertig sein bevor gezeichnet wird.Und jeder Thread ist mit einem Overhead verbunden. Das Programm wird anfälliger für raceconditions etc pp.

Schorsch

Supermoderator

Beiträge: 5 206

Wohnort: Wickede

Beruf: Student

  • Private Nachricht senden

9

30.09.2015, 11:38

Die Arbeit muss nicht unbedingt auf mehrere Kerne verteilt werden, das ist richtig. Der Rest ist meiner Meinung nach kein Argument. Auch Multithreading ist eben wie bei allem keine Patentlösung. Man muss die Probleme eben vernünftig identifizieren und sich überlegen ob der Overhead sich lohnt. Manche Aufgaben müssen auch nicht unbedingt jeden Frame bestimmt werden sondern können über mehrere Frames verteilt werden. Da benötigt man nicht unbedingt Multithreading für, es könnte aber so gelöst werden.
„Es ist doch so. Zwei und zwei macht irgendwas, und vier und vier macht irgendwas. Leider nicht dasselbe, dann wär's leicht.
Das ist aber auch schon höhere Mathematik.“

David_pb

Community-Fossil

Beiträge: 3 886

Beruf: 3D Graphics Programmer

  • Private Nachricht senden

10

30.09.2015, 12:01

nur weil man multithreading betreibt heißt es nciht dass diese Threads dann auf verschiedenen Kernen laufen
da händelt die CPU alles ganz anders als du dir das wünscht.


Ja, die Probleme von präemptivem MT sind hinreichend bekannt. Trotzdem kann man Threads mit Prioritäten versehen und sein Design so gestalten 'als ob' die Threads auf verschiedenen Kernen laufen. Das MT-Systeme ihre ganz eigenen Probleme mitbringen ist klar, aber Systeme lassen sich in Hinblick darauf implementieren. Multithreading ist ja nichts neues im Spiele-Engine-Bereich, wie bereits erwähnt setzen viele moderne Engines komplett auf multithreadgetriebene Ansätze, darüber gibts auch ne Menge spannender Informationen wo darauf näher eingegangen wird.

Alle Prozesse müssen eh fertig sein bevor gezeichnet wird.Und jeder Thread ist mit einem Overhead verbunden. Das Programm wird anfälliger für raceconditions etc pp.


Realistisch gesehen kommt ein System natürlich nie ohne Syncpoints aus, allerdings ist speziell das Zeichnen (bzw das Aufbauen der Cmdbuffer) und der CPU-Frame kein harter Fall an dem synchronisiert werden muss. Einige Engines z.B. interleaven Rendering und den 'Rest' des Frames (Simulation, Physik, Objektupdates, ...) indem das Rendering einen Frame hinterherläuft. So können effektiv Bubbles im Scheduling aufgefüllt werden, da die Tasks unabhängig voneinander sind. Und natürlich führt auch das zu verschiedenen Problemen, die besonders beachtet werden müssen.
@D13_Dreinig

Werbeanzeige