proggen.org

Für meine Spieleengine versuche ich natürlich auch meinen Code so schnell wie möglich zu schreiben, zumindest soweit es sinnvoll möglich ist und im Bereich des Lesbaren bleibt. Dabei bin ich auch auf einen Eintrag in einer Mailingliste gestoßen auf der die langsame Ausführungsgeschwindigkeit von Boost.Signals bemängelt wurde.

Das habe ich jetzt in einem Artikel auf meiner Homepage auch ausprobiert und bin mit meinem Testprogramm an ähnliche Ergebnisse gelangt. Was ich und andere auch daraus erkennen sollten, das Boost nicht immer die beste Lösung darstellt auch wenn sie sehr gute Bibliotheken sind.

Zwischenzeitlich habe ich überlegt mit einem Event/Signals and Slotssystem zu arbeiten, aber ich glaube ich werde jetzt aus Performancegrunden versuchen das so weit wie möglich einzuschränken. Weil wenn ich das zum Beispiel mit Boost.Signals machen würde und in jedem Frame 1.000 Slots jeweils 1.000 Mal aufrufen würde dann würde ich auf eine Framerate von nur knapp 30FPS kommen, und das ohne noch irgendwelche anderen Sachen zu berechnen. Mit meiner vorgestellten Alternative komme ich immerhin noch auf ca. 130 FPS, aber was auch noch zu wenig ist weshalb ich wohl andere Wege einschlagen werde

Kerli hat geschrieben:Mit meiner vorgestellten Alternative komme ich immerhin noch auf ca. 130 FPS, aber was auch noch zu wenig ist weshalb ich wohl andere Wege einschlagen werde

Bleibt Dir ansonsten keine Rechenzeit mehr? Wenn Du 130FPS mit Bild bekommst, dann reicht das imho vollkommen, die wenigsten CRTs bringen 130 Hz und TFTs sowieso nicht.

Xin hat geschrieben:Bleibt Dir ansonsten keine Rechenzeit mehr? Wenn Du 130FPS mit Bild bekommst, dann reicht das imho vollkommen, die wenigsten CRTs bringen 130 Hz und TFTs sowieso nicht.

Das würde natürlich vollkommen reichen. Normalerweise sollten so max. 60 FPS genug sein, aber hier haben allein die Signale diese Zeit benötigt. Ich wollte damit nicht sagen das ich dieses Prinzip gar nicht verwenden werde, aber eben sparsamer als zwischenzeitlich geplant. Und irgendwie wird es doch etwas unübersichtlich bzw. schwerer zum Nachvollziehen wenn alles nur über Events bzw. Signals abläuft.

Was ist denn eigentlich genau das Problem, dass Du so abbilden musst?
Ich meine - wer muss schon tausende Signale abschicken!?

Xin hat geschrieben:Was ist denn eigentlich genau das Problem, dass Du so abbilden musst?
Ich meine - wer muss schon tausende Signale abschicken!?

Das ist nicht Muss, aber es ist eine Variante auf die ich gestoßen bin. Für beinahe alles werden Events verschickt. Beim Rendern zb bekommt jedes Objekt eine Nachricht es soll sich Rendern, bei der Kollisionsabfrage schickt jedes Objekt eine Nachricht aus "Stoße ich mit dir zusammen?" oder wenn ein Objekt wissen will wo sich ein anders Objekt befindet dann schickt er diesem eine Nachricht "Wo bist du?" usw.

Und da kann es leicht auf tausende Signale kommen. Signale werde ich zwar trotzdem einsetzen, aber eben nicht so extrem...

Kerli hat geschrieben:

Xin hat geschrieben:Was ist denn eigentlich genau das Problem, dass Du so abbilden musst?
Ich meine - wer muss schon tausende Signale abschicken!?

Das ist nicht Muss, aber es ist eine Variante auf die ich gestoßen bin. Für beinahe alles werden Events verschickt. Beim Rendern zb bekommt jedes Objekt eine Nachricht es soll sich Rendern, bei der Kollisionsabfrage schickt jedes Objekt eine Nachricht aus "Stoße ich mit dir zusammen?" oder wenn ein Objekt wissen will wo sich ein anders Objekt befindet dann schickt er diesem eine Nachricht "Wo bist du?" usw.

Das klingt nach sauberer OOP... aber nicht sinnvoll...