Quader mit dynamischer bewegung

[NoGFX]

Nabend erstmal.
Bin gerade dabei Quader eine dynamische bewegung zuzuordnen. Via for-Schleife und einer dazugehörigen Funktion werden MCs mit der Form eines Quaders geladen und von ihrer Anfangsposition, zu einer neuen, dynamischen, Position geleitet. Wie man in der angehängten .swf Datei sehen kann, sind diese zum schluss allerdings relativ langsam, und man muss Ewigkeiten warten bis sie da sind, wo sie sein sollen.

Das AS für die Funktion, nicht schön, aber es erfüllt seinen Zweck (mehr oder weniger):

function create(i, x_nr, y_nr, zeahler) {
	container.attachMovie("mask", "mask"+i, i);
	container["mask"+i]._x = -1000;
	container["mask"+i]._y = -1000;
	container["mask"+i].onEnterFrame = function() {
		final_x = 39*x_nr;
		final_y = 39*y_nr;
		this._x += (final_x-this._x)/(99/zeahler);
		this._y += (final_y-this._y)/(99/zeahler);
		if (this._x == final_x && this._y == final_y) {
			this._x = final_x;
			this._y = final_y;
			delete this.onEnterFrame;
		}
	};
}

Könnte mir jemand ein paar Tipps geben, wie man die dynamische Bewegung etwas gleichmäßiger hinbekommt, so das die Quader sich nicht wie als ein gesamter Block bewegen, aber auch nicht zum Schluss so rumeiern?...
Danke schonmal

Edit:
Link zu der .swf: http://www.careaboutart.net/dyn_1.swf

 

[Rena Hermann]

[...]
 if (this._x == final_x && this._y == final_y)
[...]

Deine Koordinaten erreichen nie exakt final_x bzw. final_y.

Grund: dein Abbremsenscript, z.B. this._y += (final_y-this._y)/(99/zeahler);
Ist mit dieser Rechenmethode rein mathematisch gar nicht möglich. Du kannst dir auch mal die aktuellen Positionen ausgeben lassen -> trace(this._y) ... dann siehst du es selbst, es wird nie _exakt_ final_y, was du ja voraussetzt um den onEnterFrame-Event zu löschen.
Selbiges natürlich auch für die x-Koordinaten

Folge: deine onEnterFrames werden nie gelöscht und werden immer mehr, was das ganze langsamer macht je mehr Blöcke da sind.

Möglichkeit: Frage nicht ab ob _y == final_y ist sondern ob die Differenz z.B. kleiner als 1 Pixel ist (das dürfte erreicht werden bzw. musst testen - wiederum mit trace). In dem Fall dann _y=final_y und den onEnterFrame-Event löschen.

Gruß
Rena

 

[NoGFX]

Hab's mal umgesetzt, wenn die Positionen nun nurnoch eine differenz von max 5Pixel haben, werdensie auf ihren Platz gesetzt und das onEnterFrame wird gelöscht. Aber es hat nichts geändert, zum Schluss tuckern sie weiterhin nurnoch ziemlich langsam durch die Gegend.

(Habe 5 Pixel genommen, da ich so 100% sicher sagen kann, dass sie ihre Position erreichen und somit das onEnterFrame gelöscht wird.)

 

[Rena Hermann]

Ich nehm an, dass du dir über trace ausgeben lassen hast, dass die onEnterFrames tatsächlich gelöscht werden.

Dann wäre noch die Frage, was denn 99/zeahler ergibt? Je höher desto langsamer.

Sonst fällt mir gerade nichts mehr ein.
Gruß
Rena

 

[NoGFX]

Das mit dem 99/zeahler ist eine der Gründe wieso ich nicht verstehe, das es langsamer wird.
Die ganze Funktion wird per for-schleife aufgerufen, diese for-schleife erhöht den Werd der Variable zeahler bei jedem durchlauf um 1, bis der Maximalwert von 99 erreicht ist. Somit ist 99/ zeahler = 99/99, was 1 ergbit (yay) und somit sollte es eigentlich eher schneller laufen als am Anfang...