Vor allem, wenn man besseren Code schreibt als gewisse Leute bei Enterbrain, die es sogar geschafft haben eine Kollisionsabfrage mit O(n²) zu bringen...Zitat von MagicMagor
Vor allem, wenn man besseren Code schreibt als gewisse Leute bei Enterbrain, die es sogar geschafft haben eine Kollisionsabfrage mit O(n²) zu bringen...
--Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
Erläuter das mal genauer, bitte. o,o Also warum die Kollisionsabfrage so komplex ist und wie sie einfacher gestaltet werden könnte.
Jedes Event prüft pro frame die Kollision mit jedem anderen Event auf der Map. Lass mal einen Profiler über den Code laufen, es entwickelt sich ein echter Flaschenhals an der Stelle, wenn die Zahl der Events steigt... :/
Und besser, man könnte einfach irgendeine räumliche Datenstruktur benutzen, da bei den meisten in Frage kommenden Strukturen allerdings das Einfügen und Entfernen relativ aufwändig ist würde ich etwas noch simpleres, wie einen Hash oder dergleichen benutzen, bei dem sich die Schlüssel aus den Positionen der Events berechnen.
Da Hash's in Ruby konstante Zugriffszeit haben sollte das immer noch bei weitem effizienter sein als das bisherige...
Aber das war nur ein Beispiel das mich letztends etwas überrascht hatte, es gibt viele kleinere Dinge die den XP im Endeffekt langsamer machen als nötig wäre. Ein anderes Beispiel... die meisten Objekte basieren auf einer Art von MVC (Database, Sprite_* Klassen und Game_* Klassen), wobei das V dabei sehr lustige Verhaltensweisen an den Tag legt und selbst dann aktualisiert wird, wenn es garnicht zu sehen ist.
Ja, das war "rein zufällig" an Stelle 2 beim profiler. Graphics.update (ich denke mal da wird das ganze Zeug geblittet) kommt erst ein gutes Stück später...
--Plots in a Nutshell:
Someone the reader likes overcomes increasingly difficult obstacles to reach an important goal. ~ Author unknown
Berechtigungen
Zitieren