Bewegung zum Ziel

[joggel]

Hallo Ihr,

ich bekomme hier seltsames Verhalten.
Ich beschreibe mal was ich versuche zu erreichen:
Ich möchte ein Objekt auf den Bildschirm ständig in Bewegung halten.
Dazu generiere ich zufällige Zielpositionen (mObject.mNewTarget) und versuche mich dann eben zu diesen zu bewegen.
Sollte das Objekt das Zeil erreicht haben, wird ein neues Ziel generiert.

So sollte es zumindest theoretisch ablaufen, nur macht es das in der Praxis nicht und ich habe keine Ahnung wieso.
Es erreicht irgendwie NIE das Ziel...
Ich verstehe es nicht wieso.
Hier mal der Code:

Code: Alles auswählen

void Game::updateGame()
{
	sf::Vector2f dir = mObject.mNewTarget - mObject.mPosition;
	float lenDir = sqrt((dir.x*dir.x) + (dir.y*dir.y));
	if (lenDir < 5.0)
	{
		mObject.mNewTarget = generateNewTargetForObject();
	}
	else
	{
		dir.x = dir.x / lenDir;
		dir.y = dir.y / lenDir;

		mObject.mPosition.x = mObject.mPosition.x + (dir.x*speed*mObject.mClock.getElapsedTime().asMilliseconds());
		mObject.mPosition.y = mObject.mPosition.y + (dir.y*speed*mObject.mClock.getElapsedTime().asMilliseconds());
	}
}

Vlt könnt ihr erkennen wieso sich das nicht wie gewünscht verhält...

Gruß

[Krishty]

getElapsedTime() == 0 oder speed geringer als Geschwindigkeit des Ziels?

[joggel]

Also Ziel ist ein fix-Punkt, und speed ist somit definitiv schneller.
Und getElapsedTime() funktioniert auch soweit ich das eben getestet habe...

[joggel]

Ist ja nicht wahr....ich habe jetzt mal zum schluss der Funktion den Timer immer wieder resetet.
Somit gibt getElapsedTime() die Zeit seit dem letzten reset an.
Und jetzt funktioniert es :)

Verstehe ich zwar nicht auf Anhieb, aber es funktioniert.

[Krishty]

Also hoffentlich ist getMiliseconds() eine Gleitkommazahl, sonst bricht das Ganze zusammen, wenn ein Frame weniger als ein Tausendstel einer Sekunde dauert (und wird schon vorher verdammt ungenau) …

[joggel]

Negativ. signed int!
Aber es gibt ja auch noch asMicroseconds(), da wird es etwas genauer...

[DerAlbi]

Du solltest uns mal über die Einheiten aufklären.
Wenn "Speed" in Einheiten/Sekunde ist, ist das völliger murks.
Ansonsten: ein Integer als Zeit ist auch mist. was passiert bei >1000fps?

Was passiert, wenn Speed zu groß ist? da schießt du jedes mal übers ziel hinaus und schwingst unkontrolliert.

Kannst du nicht simpel durchdebuggen und step by step sehen, wo das Problem liegt? Oder die Positionen pro Iteration als strings in eine Datei schreiben und mit dem Editor anschauen, wenn der Debugger nich will (oder das Timing verändert)?

Gib doch auch einfach mal aus, wie weit du dich pro Durchlauf dieser Funktion bewegst.... was bekommt man schon hin^^

[joggel]

Du solltest uns mal über die Einheiten aufklären.
Wenn "Speed" in Einheiten/Sekunde ist, ist das völliger murks.

speed ist Pixel/Sekunde.
Und wieso ist das völliger murks?

Ansonsten: ein Integer als Zeit ist auch mist. was passiert bei >1000fps?

fps>1000 wird nicht passieren; ist begrenz auf 60.
Und das Integer als Zeit-Einheit verwendet werden gibt das Framework vor...

Kannst du nicht simpel durchdebuggen und step by step sehen, wo das Problem liegt? Oder die Positionen pro Iteration als strings in eine Datei schreiben und mit dem Editor anschauen, wenn der Debugger nich will (oder das Timing verändert)?

Da es jetzt funktioniert und zeit auch begrenzt ist, will ich mir diese arbeit eigentlich nicht machen...

[Krishty]

Naja, es ist deshalb murks, weil Pixel/Sekunde*getMiliseconds() nicht Pixel ergibt, sondern Tausendstelpixel. Du musst speed also tausend Mal höher angeben.

Wenn die fps auf 60 begrenzt sind ist das in Ordnung (ruckelt das jetzt auf meinem 85-Hertz-Monitor?); oft genug hat man das aber leider nicht und dann geht es eben auf schnellen Systemen schief.

[joggel]

Und was empfiehlt sich da anders zu machen?

[Krishty]

Mit den Einheiten oder mit den FPS?

[joggel]

Mit den fps.

[Krishty]

Mit festen FPS bist du schon nah dran, aber man nimmt üblicherweise eine hohe Zahl (entkoppelt von der Grafik) mit vielen glatten Teilern (sowas wie 120; bei Engines mit hohen Ansprüchen habe ich auch mal von 640 gehört). Dadurch rennt die Physik pro Grafikframe einmal, zweimal, oder öfter durch – je nachdem, ob das System schnell oder langsam ist – aber auf jeden Fall in gleichmäßigem Muster. Je höher die Physikrate, desto glatter sind dabei die Bewegungen.

Ist das bei deinem Code nötig, dass jedes Objekt eine eigene Uhr hat? Werden die in unterschiedlichen Abständen aktualisiert?

[joggel]

Also das mit der Uhr ist eigentlich nicht nötig das jedes objekt eine eigene hat.
Es genügt eine "globale" uhr.

[Krishty]

Jau. Dann kannst du *vor* der Schleife die Uhr abfragen, die Zeitspanne zu float konvertieren, durch 1000.0f dividieren (damit sie in Sekunden vorliegt statt in Milisekunden) und dann ist speed auch wieder in Pixel/s. Wenn du dann doch Nanosekunden oder sowas nehmen willst, geht das fast ohne Mehraufwand :)

[joggel]

Alles kloar. Werd mal sehen ob ichs umsetzte...