Kann man diesen Code noch schneller machen?

[Winn]

Rofl, stimmt... muß an der Hitze liegen, aua aua :o

[volkard]

sehe keine große beschleunigung.
die ist vermutlich dort zu suchen, wo diese zeilen zu oft aufgerufen werden.

[Mr. N]

Original erstellt von Optimizer:
Diese 3 Zeilen verbrauchen mehr als 97% der Rechenleistung.

_Das_ wirst du nicht verringern _wollen_.

[dEUs]

[?]

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?

[Gast]

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.

[Profi]

Schon mal nen Profiler genutzt?

[Walli]

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).

[Donald E. Knuth]

premature optimization is the root of all evil

[Walli]

Original erstellt von <Donald E. Knuth>:
premature optimization is the root of all evil

Das 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...

[Donald E. Knuth]

das war nicht auf dich, sondern auf Optimizer bezogen. Dein Vorschlag ist nicht premature optimization, sondern vernünftig.

[Gast]

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.

[volkard]

Original erstellt von Optimizer:
Das einzige was noch sinnvoll scheint, ist die Map in Regionen aufzuteilen.

you got it!

[Gast]

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. ]

[PeterTheMaster]

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. ]

[Erhard Henkes]

Warum braucht man überhaupt float oder double? Reicht int oder short int nicht aus?

[PeterTheMaster]

weisst du wie gross seine karten sind? und mit double ist es auf jeden fall generischer. in opengl kann man sogar farben als doubles angeben. man weiss nie, was die hardware oder engine mal zu leisten in der lage sein wird.

[Gast]

Die Einheiten bewegen sich nicht in Grids! Sie können an jeder beliebigen Position stehen und jeden beliebigen Bewegungsvektor haben, z.B.
.x = 1.47538
.y = 0.37642

Es gibt auch keinen "Abschluss einer Bewegungsphase", das Spiel läuft in Echtzeit. Ich kann also entweder nach jedem Schritt die Prüfung machen, oder in regelmäßigen Abständen (alle 50 Schritte), so wie ich es jetzt mache. Ich glaube, da gibt es nicht mehr viel zu verbessern.
Meine Frage mit den Regionen ist rein technischer Natur. Soll ich speichern, in welchen RegionEN (wenn die Einheit am Rand ist muss ich die benachbarte Region mittesten) eine Einheit ist, oder welche Einheiten in einer bestimmten Region sind?
Und WIE speicher ich das?
Wer sich das Spiel übrigens mal anschauen will, der Link steht unten.

Danke für Hilfe schon mal im vorraus.

[Gast]

C:\GAME_0~1.EXE
Die NTVDM-CPU hat einen ungültigen Befehl entdeckt.
CS:0f65 IP:01b8 OP:63 6f 6e 74 65 Klicken Sie auf "Schließen", um die Anwendung zu beenden.

[Gast]

hatte speichern unter benutzt. und dann stand der html quelltext in der exe