Ich brauche eure professionelle Meinung zu meinem "Algorithmus"

[Jaiel]

Hey Community,

es geht um folgendes: Ich habe ein spiel und in diesem muss ich sagen wir mal um es einfacher zu machen ein Ball zu einem bestimmten Punkt in 2D bewegen. Jetzt hat der Ball eine vorgegebene Geschwindigkeit, zum Beispiel 100 px/dpi pro sekunde. Den Punkt soll er in eienr geraden Linie erreichen und dafür muss ich die jeweiligen Geschwindigkeiten in X bzw. Y - Richtung berechnen. Also falls der Ball einfach nach rechts oder links rollen soll ist die Geschwindigkeit in Y richtung ja gleich 0 und Umgekehrt genau dasselbe ich hoffe ihr könnt mir folgen.

So jetzt habe ich mit Hilfe von Pythagoras diesen "Algorithmus" gebastelt:

/** 
*  Sets the velocity for the Objects movement in x/y- direction.
* tarX/tarY  - are the targeting x/y - coordinates
* posX/posY - are the current x/y - positions of the object
* velX/velY - are the velocities in x/y - directions(px/ms)
* vel - the velocity (vector) of the object (px/ms)
* delPos - is the distance between the targeting position and the current position
*/

public void setVelocity()
	{
		delPos=(float) Math.sqrt((this.tarX-this.posX)*(this.tarX-this.posX)
				+(this.tarY-this.posY)*(this.tarY-this.posY));
		
		if ((this.posX-this.tarX)*(this.posX-this.tarX)<=900)this.velX=0;
		else if(delPos!=0) this.velX=this.vel*(this.tarX-this.posX)/delPos;
		
		if ((this.posY-this.tarY)*(this.posY-this.tarY)<=900)this.velY=0;
		else if(delPos!=0) this.velY=this.vel*(this.tarY-this.posY)/delPos;
	}

die Abfrage

if ((this.posX-this.tarX)*(this.posX-this.tarX)<=900)

also ob der Abstand zwischen den koordinatenstellen des Objektes zu seinem ziel im Quadrat 900 (also 30 px/dpi) mache ich damit das Objekt nciht über das Ziel hinausschießt sondern in einem bestimmten Bereich stehen bleibt. Und ich quadriere das damit ich den Betrag rausbekomme denn posX-tarX kann ja auch negativ sein da wollte ich nciht ne doppelte if anweisung amchen ob posX-tarX< 30 und größer -30) ist.

Der Rest ist simple Mathematik ich bin da aber auch nciht intuitiv drauf gekommen beim ersten Mal: er hat ne geschwindigkeit von wie gesagt 100 pixel/sekunde er hat die Entfernung von seiner position zu der anvisierten

wenn die z.B. 200 pixel wäre dann errechnet er den faktor um den er sich in X/Y richtung bewegen muss um in 2 sekunden bei dieser x stelle zu sein bewegen muss((100px/s)/(200px))=0.5/1s).
So und diesen Faktor rechnet er mal die Differenz der Punkte. Wäre der Abstand also sagen wir mal 150 px zwischen den X stellen dann muss der ball sich eben um 0.5*150 px/sekunde = 75 pixel in x richtung pro sekunde bewegen!
(ich hab mir sowas von an den Kopf gefasst weil ich das auf dem Blatt über sinus tangens und was weiß ich was alles ausgedacht habe)

Naja meine Frage lautet kann man diesen code noch so ändern dass ich nciht auf Math.sqrt(...) zurückgreifen muss?


Ich blicke da grad nciht hinter ob das irgendwie anders geht ....

Der ursprüngliche Beitrag von 19:52 Uhr wurde um 19:55 Uhr ergänzt:

Es sollte aber ein Code werden der nciht noch komplizierter und länger als dieses original werden soll

 

[hävksitol]

Zeitaufwendige (häufig durchgeführte!) Funktionsaufrufe kann man immer (alter GFA-Basic-Trick [ATARI ST!], also eigentlich nur was für extrem langsame CPUs) durch (vorberechnete) Felder ersetzen, also z.B. (in Pseudo-Code):

float Wurzel[2000]
.
For i=1 to 2000
Wurzel := sqrt(i);
next i
.
.
delPos= Wurzel[int(Hier wird gerechnet)]

Die Vorabberechnung (die ja selbst Zeit kostet) macht natürlich nur dann Sinn, wenn delPos öfter aufgerufen wird, als Wurzel[] Feldelemente hat; außerdem muß das Ergebnis der Rechnung innerhalb der [] auf eine INT reduziert werden, da nur/damit ein ganzzahliger Index von Wurzel angesprochen werden kann.

Was genau stört Dich denn an der Verwendung von SQRT?

 

[kosmus]

Alter Grundsatz:
Make it run,
Make it clean,
Make it fast.

Ich würde mich erst mit der Lösung von performance problemen beschäftigen, wenn sie auch auftreten. Vor berechnete Werte machen den code unübersichtlich und erhöhen den Wartungsaufwand. Sollte man m.E. nur machen wenn es auch nötig ist.

 

[Jaiel]

danke kosmus und hävksitol für eure antwortzen:

hävksitol ich muss da kosmus rechte geben und es ist mir ein viel größerer dorn im auge jetzt nohcmal 2000 float im code zu haben.....mmmmh was mcih an sqrt stört ist einfach das es lönger braucht als + - * und / ich dachte vielleicht kann man die formel so umformen dass man nur die grundrechenoperationen benutzen muss!

 

[hävksitol]

Hallo Jaiel,

meine Antwort war der - zudem von mir selbst implizit als möglicherweise obsolet konzedierte - Versuch einer Antwort auf Deinen Startbeitrag, bei dem nicht klar war, worum es dir eigentlich ging, zumal der Titel "Ich brauche eure professionelle Meinung zu meinem "Algorithmus"" und das Beifügen des Sourcecodes den Leser in eine ganz andere (d.h. die von mir vermutete Richtung) Richtung wiesen. Letztendlich reduziert sich Deine Frage aber auf das (mathematische, jedoch nicht wirklich programmiertechnische) Problem, eine Wurzelberechnung (die bei Pythagoras nunmal zwingend nötig ist) nur unter Benutzung der Grundrechenarten durchzuführen; wie das geht (& daß Du das garantiert nicht selbst implementieren willst!), kannst Du z.B. hier und hier nachlesen.

 

[DieGoldeneMitte]

(Repost, keine Ahnung was der Mod für ein Problem mit dem Vorpost hatte.)

Wegen einer(!) Wurzel pro Bildaufbau (wenn ich das Problem richtig verstanden habe) sollte man sich keinen Kopf machen.

Wurzelberechnungen sind schnell und effizient in modernen Prozessoren verdrahtet (und je nach Implementierung sind solche vermeintlich schweren Operationen sogar schneller als Multiplikationen).

Wenn du deinen Algorithmus verbessern willst, würde ich sagen, dass du ihn lesbarer machen solltest und die Differenzen in Zwischenvariablen (dx = this.posX - this.tarX) speichern solltest.

 

[Jaiel]

ja ok hast schon recht une es sind ein paar mehr aufrufe denn diese funktion hab ich in meiner klasse MovingObjects impementiert die alle objekte erben und das werden dann höchstens 25 sqrts sein MAXIMAL aber deswegen meine bedenken