spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Was heißt "es haut die FPS runter"? Von 700 auf 550? Und wie machst Du das genau?

• Space Partitioning nutzen, rekursiv unterteilen (Octree, Quadtree, ...)
  
• Einfache Collision shapes (Sphere, Capsule = 2 Spheres + 1 Cylinder) nutzen, statt komplexe (Box, Mesh, ...)
  
• Mathematik vereinfachen: Wurzeln und Divisionen vermeiden
  Beispiel:
  

  	C-/C++-Quelltext
  1 2 3 4 5 6 7	// schlecht: if (sqrt(vec.x*vec.x + vec.y*vec.y) == length2) ... a = b / 2; // besser: if ((vec.x*vec.x + vec.y*vec.y) == length2 * length2) ... a = b * 0.5;

  
  
• ...
  

Und wie machst Du die Kollisionserkennung?

Bei 35 FPS würde das nicht ruckeln....

Wie gesagt, iSmokiieZz hat dir einige Lösungsansätze gegeben, diese müssen nur noch implementiert werden. Auch empfiehlt es sich Occlusion Culling zu nutzen, hat zwar weniger etwas mit Kollisionerkennung zu tun,
aber kann die FPS trotzdem deutlich hoch schrauben.

Außerdem, ich bin nicht gut in Deutsch, aber ich glaube du meintest "Performanceeffektiv" ?

Er meint damit "schnell"

Zitat von »iSmokiieZz«

	C-/C++-Quelltext
1 2 3 4 5 6 7	// schlecht: if (sqrt(vec.x*vec.x + vec.y*vec.y) == length2) ... a = b / 2; // besser: if ((vec.x*vec.x + vec.y*vec.y) == length2 * length2) ... a = b * 0.5;

Ist beides schlecht. Der Vergleich wird wahrscheinlich nie true ergeben.
Wer vergleicht denn zwei floats mit "=="?!

Ausserdem macht der Compiler aus einer solchen Division sowieso eine Multiplikation. Es ist völlig egal was man schreibt.

Zitat von »NachoMan«

Wer vergleicht denn zwei floats mit "=="?!

Zuviele...

Zitat von »NachoMan«

Außerdem macht der Compiler aus einer solchen Division sowieso eine Multiplikation. Es ist völlig egal was man schreibt.

Ich habe es gerade mal überprüft... Der MSVC macht es in dem Fall tatsächlich.
Verlassen kann man sich darauf aber nicht, weil der Compiler durch IEEE 754 bei Standardeinstellungen leicht übervorsichtig ist. Umformungen die Mathematisch kein Problem sein sollten werden nicht durchgeführt, weil es zu anderer Rundung oder Probleme bei Unendlichkeiten/NAN führen würde. "/ 3.0" wird zum Beispiel nicht automatisch in " * (1.0 / 3.0)" umgeformt, außer wenn man explizit "fast math" aktiviert. In der Regel schadet es nicht es gleich richtig hinzuschreiben. Auf mathematische Float-Umformungen würde ich mich deshalb besser nicht verlassen.

Ich halte es allerdings für unwahrscheinlich, dass das das Problem des Fragestellers ist. Wenn es so wäre, sollte er auch über seine Vorgehensweise nachdenken, weil vermutlich noch irgend etwas anderes schiefläuft. Vielleicht mal profilen? Ein derartiger Einbruch dürfte durch soetwas Grundlegendem bei einem halbwegs normalen Spiel niemals ausgelöst werden.

LetsGo even further offtopic and post useless commentars...

Ich denke es ist klar geworden, was ich mit dem Codeschnipsel sagen wollte. Dass floating point precisions beim comparen ein Problem sein können spielt bei der Performance keine Rolle. Ich bin mir sicher, dass ihr das wisst.

Tragt doch bitte weitere Möglichkeiten zur Verbesserung der Performance bei, anstatt destruktiv zu agieren. Das nützt dem Fragesteller sicher mehr.