Perfomencproblem!

Rodrog · 2. November 2011, 19:47

Guten Abend Leute,

und zwar ich brings gleich mal auf den Punkt. Ich hab ein Problem bezüglich der Performence meiner Objekte. Meine bisherigen Spiele waren alle immer in kleine Räume aufgeteilt. Jedoch hab ich jetzt in einem Spiel einen 2560x2560px großen Raum und in diesen Raum hab ich viele Bäume zufällig erstellt.. Jetzt gibt es Probleme in manchen Objekten, da sie die Kollision der Bäume überprüfen müssen, und dadurch beginnt mein Spiel zu "laggen".. da dies eines meiner ersten Spiele ist, das so eine große Anzahl von Objete nutzt, also Bäume.. weiß ich nicht genau wie ich das am besten Lösen kann..

Zuerst hatte ich alle Objekte außerhalb des Views deaktivert jedoch, müssen die Objekte trotzdem aktiviert sein.. zum Beispiel hab ich ein Sägewerk das städig Holz abbaut und somit auch weiterarbeiten muss, auch wenn ich ihm nicht sehe, also außerhalb des Views.

Ich hab mir schon einige Sachen überlegt, aber würde trotzdem die beste Methode wissen..
Einer meiner Ideen war das ich allen Bäumen einer View ein DummyObjekt draufcreate, und mit dem DummyObjekt wird die Collision überprüft und nicht mit dem Baum selbst.

MfG

Mr. Diesel · 2. November 2011, 20:34

Ach, haben wir dieses Problem nicht alle?

Ich würde vorschlagen, dass du unpräzise Kollisionen nimmst,
dann muss der GM weniger überprüfen und der Spieler merkt
davon auch herzlich wenig. Also beim Sprite "percise collision checking"
den Hacken weg. Mehr dürfte sich eigentlich auch nicht machen lassen.

Rodrog · 2. November 2011, 21:19

Ich hab schon die unpräzise Kollision, und trotzdem laggt es^^
Es geht ja nicht um die Kollision selber sondern wie ich das doch relativ besser in grief bekomme..
Man kann den Code ja immer verbessern, es gibt immer eine Möglichkeit in zu verbessern oder komplett umzuschreiben. Ich würde nur wissen wie ihr das lösst um bei mir das bisschen besser hinzubekommen

MfG

Firestudios · 3. November 2011, 10:25

Ich glaube du kannst Objecte deaktivieren die ausser reichweite des views sind.
Wenn du dann in die naehe kommst also ins view, werden sie aktiviert.
Aber bitte frag mich nicht wie das geht

Also hier wird das sicher jemand wissen

Wer es weis schreibt es hier bitte rein. Ich brauche das selber

Rodrog · 3. November 2011, 11:38

Firestudios schrieb:

Ich glaube du kannst Objecte deaktivieren die ausser reichweite des views sind.
Wenn du dann in die naehe kommst also ins view, werden sie aktiviert.
Aber bitte frag mich nicht wie das geht
Also hier wird das sicher jemand wissen
Wer es weis schreibt es hier bitte rein. Ich brauche das selber

Rodrog schrieb:

Zuerst hatte ich alle Objekte außerhalb des Views deaktivert jedoch, müssen die Objekte trotzdem aktiviert sein.. zum Beispiel hab ich ein Sägewerk das städig Holz abbaut und somit auch weiterarbeiten muss, auch wenn ich ihm nicht sehe, also außerhalb des Views.

Also das geht relativ einfach

GML-Quellcode

instance_deactivate_all(true);
instance_activate_region(view_xivew[0],view_yview[0],view_xview+view_wview[0],view_yview+view_hview[0]);
//Hab das jetzt nur so runtergetippt, ich hoffe ich hab keinen Tippfehler drinnen

Wie gesagt kann ich es nicht einfach so deaktivieren, da ich auch einige Bäume außerhalb des Views immer benötige.

MfG Rodrog

MasterXY · 3. November 2011, 12:03

Auch die Art der Kollisionsüberprüfung wirkt sich auf die Performance aus. Die meiste Performance wird wohl das GM-Interne Kollisions-Event ziehen, noch schlimmer ist es dann, falls du die Kollision im Baum Objekt überprüfst (Viele Baumobjekte => viele Überprüfungen). Das Beste ist, wenn du erstens eine simple Bereichsüberprüfung bzw collision_point oder circle Funktion benutzt, und diese dann auch in dem Objekt, das weniger oft im Raum vorkommt.

Lucke · 3. November 2011, 13:46

Ich habe mir jetzt zwar nicht das gesammte Gespräch durchgelesen aber wenn Kollisions-Evente wirklich so viel Performace ziehen dann lös es doch über eine Variable, wenn die distance zum Objekt gering ist, dann true, also werden Kollisionen gecheckt und falls nicht false dann nicht.
Ziemlich simple sollte doch aber eigentlich funktionieren ;)

// Lucke //

Irrenhaus3 · 3. November 2011, 14:33

Das kommt mir irgendwie bekannt vor. Bei meinem aktuellen Projekt besteht aus offensichtlichen Gründen ein ähnliches Problem: Das eigentliche Spielfeld ist nicht so groß wie der ganze Raum, daher hatte ich bis vor kurzem die Abfrage eines Triggers in den Kugelobjekten; dieser gibt true zurück, sobald die Kugel das Spielfeld verlässt, damit sie zerstört werden kann - aus Performancegründen halt. Ironischerweise führte das zu dermaßen massiven FPS-Einbrüchen (unter 55 von 60 bei ca. 200 Kugeln), dass ich mal rumprobieren musste, was man da so alles machen kann. Ich stellte fest:

Trigger in jedem Step abfragen = Schlecht. Massive Performanceprobleme.
Auch nur ein einziges Kollisionsevent pro Kugel = Schlecht, aus den selben Gründen
outside-room-Event = Gut! Die fps fielen erst bei ca. 5000 Kugeln unter 55.
Gar nix, manuelle Zerstörung zu bestimmten Zeitpunkten = Optimum, erlaubte bis zu 8000 Kugeln gleichzeitig.

Wie stark die Performance einbricht hängt also davon ab, wie viel Code deine Objekte pro Step ausführen müssen. Vor allem Trigger und Kollsionsevents fallen da hart ins Gewicht. Wie schaut das denn bei deinen Baumobjekten aus? Fragen die Stepweise dauernd was ab? Haben sie mehrere draw-Befehle? Denn die hauen auch ganz schön rein.
Stecken die Kollisionsevents in den Bäumen oder in den Objekten, die die Bäume verwerten? Wenn ersteres: Urgs... besser schnell ändern. Wenn zweiteres: Wie viele Objekte sind das denn so im Schnitt?

Rodrog · 3. November 2011, 15:27

MasterXY schrieb:

Auch die Art der Kollisionsüberprüfung wirkt sich auf die Performance aus. Die meiste Performance wird wohl das GM-Interne Kollisions-Event ziehen, noch schlimmer ist es dann, falls du die Kollision im Baum Objekt überprüfst (Viele Baumobjekte => viele Überprüfungen). Das Beste ist, wenn du erstens eine simple Bereichsüberprüfung bzw collision_point oder circle Funktion benutzt, und diese dann auch in dem Objekt, das weniger oft im Raum vorkommt.

Ich benutze relativ oft place_meeting() und sonst eig. nichts.

Lucke schrieb:

Ich habe mir jetzt zwar nicht das gesammte Gespräch durchgelesen aber wenn Kollisions-Evente wirklich so viel Performace ziehen dann lös es doch über eine Variable, wenn die distance zum Objekt gering ist, dann true, also werden Kollisionen gecheckt und falls nicht false dann nicht.
Ziemlich simple sollte doch aber eigentlich funktionieren
// Lucke //

Das bringt sich leider nicht wirklich was

das es nicht das is was ich brauche, aber danke

@Irrenhaus3:
Ich habe ca. 5100 Bäume auf einen 2560x2560px großen Raum verteilt. Im BaumObjekt ist Step und Draw leer.. ich benötige nur das Create-Event.
Das einzige was ich manchmal abgefragt habe, was gerade entfernt worden ist, da es alle Bäume durchprüft und mir den Baum gibt der in einen Raster von 96x96pixel mit einer Variable die auf false ist zurückgibt. Ich hatte ein width benutzt, das war aber irgendwie voll performence lässtig, da ja jeder Baum durchgeprüft werden muss, hab es jetzt so gemacht das ich nur die Objekte prüf die in dem 96x 96x pixel raster auch sind.

Naja ich weiß nicht wirklich warum, aber ich hab jetzt mal alle Objekte deaktiviert und nur den Baum aktiviert.. leider hab ich trotzdem nur 25/30 FPS. Mein Laptop ist nicht wirklich der aktuellste jedoch auch nicht schlecht..

Hatte heute eine Idee, auf die mich mein Freund brachte. Ich deaktiver alle Objekte und aktivier nur die Objekte die ich sehe UND die wichtig sind (d.H.: Sägewerk, Apfelgarten usw.) und da jedes Sägewerk weiß welcher Baum gerade bearbeitet bzw. gefällt wird, wird dieser Baum auch von dem Sägewerk aktiviert. Mit dieser Idee läuft es zurzeit recht gut und hab konstante 30 FPS.

Also zurzeit läuft alles wie gehabt auf seine 30 FPS und sobald ich wieder enormen FPS verlust habe, meld ich mich wieder und ab jetzt versuch ich dieses with zu vermeiden, da dies glaub mein Hauptperformencetöter war

mfg