Ayumi, ohne dir zu nahe treten zu wollen, aber so wie ich das sehe hast du zwei Probleme
1) Du optimierst Dinge von denen du **glaubst** das sie das Problem sind
2) Du machst dir Dinge unnötig kompliziert indem du versuchst schlauer zu sein als das Problem

Zum ersten; Bitte, bitte, bitte niemals versuchen die performance zu steigern wenn du nicht weißt was genau die Performance killt! Performance optimierung läuft in dem du per profiler guckst was wieviel Zeit kostet, wo du am meisten Zeit verschwendest und dann kümmerst du dich darum. Nimm die low hanging fruits. Manchmal ist es recht einfach zu raten wo das Problem liegt, aber in der Regel ist das sehr sehr schwer einzuschätzen und du machst dir nur mehr Arbeit wenn du phantom Probleme löst.

Zum zweiten; Warum braucht dein Gras actions? wait() ist eine wunderschöne Funktion, aber sie kommt zu einem sehr heftigen Preis. Tausende von actions die per wait() "gleichzeitig" laufen, kosten eine unglaubliche Menge an Zeit. Nicht nur weil Funktionsaufrufe generell teuer sind (einer der Gründe warum tail-call optimization in fast jeder Sprache implementiert sind), sondern weil wait() auch noch sehr viel Magie im Hintergrund wirken muss um den Stack wiederherzustellen. Das Gras auf invisible zu schalten halte ich auch für eher unwirksam, die Engine culled automatisch so gut wie alles nicht sichtbare weg und wird es nicht rendern, die paar Grasbüschel die da durchfallen sind es nicht wert das jedes gras pro Frame etwas tut! Und wenn das doch das Problem ist, dann mach das in einer Funktion die pro Frame durch das gras durch geht und guckt wie ob es sichtbar ist oder nicht (wobei das auch immer noch langsam ist, vec_dist() ist zwar nicht unbedingt eine langsame Operation, aber nichts was du ein paar hundert tausendmal pro Frame machen willst. Viel besser wäre hier wohl ein spatial hash, aber, und das ist der springende punkt; Bevor du irgendwas machst, guck ob es das Gras überhaupt das Problem ist, danach und wirklich erst danach, kannst du dir tolle optimierungen überlegen).

Edit:
Quote:
EDIT: Wie gesagt, ich mache das aus Spass mit dem Ziel, eines Tages die selbe Performance wie in UT zu erreichen und letztenendes etwas vorzeigbares und spielbares zu haben.Da ist jede noch so kleine Optimierung willkommen:)

Noch zwei weitere Punkte
1) Bitte behalte im Hinterkopf das Spiele Schall und Rauch sind. Viele unglaublich tolle Effekte sind eine ungeheure schusterei und trickserei, die alle möglichen Dinge ausnutzt um den Effekt performant zu ermöglichen. Quasi jedes Post Mortem zu Spielen ist eine Sammlung von anekdoten von schmutzigen Tricks die gemacht wurden um wunderschöne Effekte zu zaubern, und wenn du probierst das straightforward selber zu implementieren, fällst du in der Regel auf die Nase. Das heißt nicht das die Engine schlechter ist, sondern einfach nur das jemand mit sehr viel Ahnung und viel Zeit sich hingesetzt hat und das einmal ausgetüftelt hat um es so hinzukriegen wie es ist.
2) Kleine optimierungen sind schön, aber nur wenn sie VIEL bringen. Wenn du performance steigern willst, fang mit dem an was am meisten performance kostet. Danach kannst du immer noch die anderen Dinge angucken und optimieren, aber bitte fange mit den Dingen an die am meisten Zeit benutzen.

Und noch etwas was HeelX schon leicht angedeutet hatte; random() ist böse. Ein Zufallszahlengenerator sorgt nicht automatisch für eine normal Verteilung, und so etwas wie wait(random(5)) mag zwar wie eine gute Idee klingen, ist aber non-deterministisch und geht garantiert in die Hose. Zufallszahlen sind noch einmal so eine Sache für sich, und vor allem sind sie eines; Nur pseudozufällig.

Last edited by JustSid; 02/19/13 13:51.

Shitlord by trade and passion. Graphics programmer at Laminar Research.
I write blog posts at feresignum.com