Kann man diesen Code noch schneller machen?
-
Dann brauchste doch auch nicht mehr die Quadrate in, so daß
const int distance = X + Y;wäre zwar mathematisch inkorrekt, aber wäre halt ne Abschätzung
Winn
-
Achtung, Achtung
Dadurch wird das Ergebnis verfälscht... ein Abstand ist normalerweise etwas absolutes, das heißt etwas positives.
Durch das quadrieren werden die einzelnen Abstände auch absolut, bzw. positiv
Das kann man nicht einfach weglassen
-
Öhm, okay... seh ich ein
Dann halt:
const int distance = abs(X) + abs(Y);Winn
-
Das bringt falsche Ergebnisse. Der Punkt (0,6) hat nen Abstand von 6 vom Ursprung, der Punkt (3,4) einen von 5. Ist also näher dran. Nach deiner Ersatzformel wären die Abstände 6 und 7, wodurch der zweite Punkt auf einmal weiter weg wär als der erste.
=> Tonne.
-
Rofl, stimmt... muß an der Hitze liegen, aua aua :o
-
sehe keine große beschleunigung.
die ist vermutlich dort zu suchen, wo diese zeilen zu oft aufgerufen werden.
-
Original erstellt von Optimizer:
Diese 3 Zeilen verbrauchen mehr als 97% der Rechenleistung._Das_ wirst du nicht verringern _wollen_.
-
-
Original erstellt von Optimizer:
Diese 3 Zeilen verbrauchen mehr als 97% der Rechenleistung.Der Gesamtrechenleistung? Oder nur der Rechenleistung für den Abstand zu berechnen?
-
Ne, für die Zielerfassung. Ich schreib ein Strategiespiel, und ich prüfe in Regelmäßigen Abständen, ob eine der Feindeinheiten in Reichweite kommt.
-
Schon mal nen Profiler genutzt?
-
Original erstellt von Optimizer:
Ne, für die Zielerfassung. Ich schreib ein Strategiespiel, und ich prüfe in Regelmäßigen Abständen, ob eine der Feindeinheiten in Reichweite kommt.Ich glaube es wäre effizienter wenn die Feindklasse sich meldet falls die Einheit sich bewegt. Dann kannst du prüfen wenn es nötig ist und nicht in Zeitabständen (dies kann ja auch unnötig sein wenn die Einheit 10 Minuten still steht).
-
premature optimization is the root of all evil
-
Original erstellt von <Donald E. Knuth>:
premature optimization is the root of all evilDas ist klar, aber man sollte wenigstens die Grund-Elemente des Programms von vorne herein überdenken, sonst hat man nachher viel Aufwand alles umzubauen. dazu sind dann viele zu faul. Das ist der Grund für langsame Programme. Klar, dass eine endgültige Optimierung erst statt finden kann wenn das Programm richtig läuft...
-
das war nicht auf dich, sondern auf Optimizer bezogen. Dein Vorschlag ist nicht premature optimization, sondern vernünftig.
-
Das funktioniert so einfach nicht. Es können sich entweder alle 200 Feindeinheiten bewegen, oder die eine Einheit, für die ich gerade prüfe, kann sich bewegen. In diesem Fall muss ich auch wieder mit allen 200 Einheiten testen.
Das einzige was noch sinnvoll scheint, ist die Map in Regionen aufzuteilen.
-
Original erstellt von Optimizer:
Das einzige was noch sinnvoll scheint, ist die Map in Regionen aufzuteilen.you got it!
-
Prob is, ich hab ka, wie ich des speichern soll, in welcher Region sich eine Einheit befindet. Ich muss sie ja auch in die umliegenden Regionen reintun, weil sie sich ja am Rand befinden kann.
Soll ich da ne Member-Var in der Klasse Einheit reinmachen, oder soll ich des von den Regionen aus speichern, welche Einheiten da drin sind.
So langsam befindet sich der Thread im falschen Forum[ Dieser Beitrag wurde am 09.06.2003 um 14:39 Uhr von Optimizer editiert. ]
-
ist das spiel rundenbasiert oder echtzeit?
ueberpruefst du wirklich in regelmaessigen zeitabstaenden die erreichbarkeit? das waere schwachsinn.
richtiger waere entweder nach abschluss der bewegungsphase oder bei echtzeit immer nachdem sich eine einheit bewegt hat. und dann natuerlich nur abstaende zu dieser einheit, nicht alles neu berechnen.
das mit den regionen macht nur sinn, wenn es einen maximalabstand gibt, den nie eine waffe ueberschreiten kann (oder du braeuchtest einen regioneneinteilung pro entfernung(-sklasse), dann muesstest du natuerlich pro region speichern, welche einheiten darin sind, und bei einem erreichbarkeitstest nur die region der schiessenden einheit und die 8 angrenzenden ueberpruefen).
sinnvoll waere auch bounding boxen zur beschleunigung der treffbarkeitsuntersuchung zu verwenden.
also statt
//r sei quadrat der reichweite der waffe int x = pos.x-unit.x; int y = pos.y-unit.y; if(x*x+y*y<r){ //treffbar }besser
//r sei reichweite der waffe, rr==r*r int x, y; if(x=pos.x-unit.x < r && y=pos.y-unit.y < r && x*x+y*y<rr){ //treffbar }das waere zwar noch empirisch zu untersuchen, aber ich nehme mal an, dass das in den meisten spielsituationen einen vorteil bringt (es sei denn, ganz viele einheiten hocken aufeinander, aber vergleiche sind ja auch nicht so teuer, profile es halt mal so und teil uns mit, was rauskommt.)
auch koennte eine double multiplikation schneller sein als float. wodurch dann das casten wegfallen koennte. ich weiss aber nicht, wie teuer ein double vergleich ist.
[ Dieser Beitrag wurde am 09.06.2003 um 15:49 Uhr von PeterTheMaster editiert. ]
-
Warum braucht man überhaupt float oder double? Reicht int oder short int nicht aus?