Bewegungs berechnung

  • VB.NET

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von Klenix.

    Bewegungs berechnung

    Hallo Leute,
    hab das Problem mit meiner List jetzt endlich fertig gebracht und stehe nun vor einem neuen Problem...
    Die bewegung in nach oben/unten/recht/links ist ja recht einfach, auch noch in die ecken usw... aber wenn ich nun auch die minimap klicke kommen nicht immer nur solche positionen raus...
    Noch kurz wie ich die Positionen erstelle.
    Das ich mehr Spielraum habe mit geschwindigkeit der figur habe ich alle positionen sehr groß gemacht, also alle * 100. Das bringt mir so gesehen mehr variationsmöglichkeiten. Wenn meine Figur nun eine Geschwindigkeit von 270 hat, bedeuted das, das sie pro sekunde 270 meiner entfernung zurücklegen soll, nach links recht usw wäre das nun wieder einfach aber wenn ich jetzt z.B.
    einen solchen winkel habe, weiß ich nicht wie ich das berechnen soll...
    es sollte eine flüssige bewegung sein, also würde ich es in 1/10 sekunde berechnen mit z.b. 27 anstatt der 270.
    ich hoffe ihr versteht was ich meine...

    Mit freundlichen Grüßen
    Klenix

    Du könntest ja mit Polarkoordinaten arbeiten. Diese bestehen im gegensatz zu den Karthesischen Koordinaten die aus X/Y-Koordinate bestehen eine Längen-/Winkel-Angabe und lasen sich ganz einfach auf Karthesischen Koordinaten umrechnen.

    hmm,
    ich hab von jemandem nen c++ beispiel bekommen, wenn es das richtige ist... Aber ich versteh das net so ganz...
    vielleicht kann das ja mal einer erklären...

    Quellcode

    1. void Move(int x, int y) {
    2. destination.x = x;
    3. destination.y = y;
    4. if(timeTaken == 0)
    5. return;
    6. if(destination.x == posX && destination.y == posY)
    7. return;
    8. delta.x = destination.x - posX;
    9. delta.y = destination.y - posY;
    10. double length = Math::Sqrt((delta.x*delta.x)+(delta.y*delta.y));
    11. timeTaken = (length/speed)*1000;
    12. normal.x = delta.x/length;
    13. normal.y = delta.y/length;
    14. curTime = 0;
    15. velocity = length/(timeTaken/10);
    16. step.x = normal.x*velocity;
    17. step.y = normal.y*velocity;

    Satz des Pythagoras.

    a² + b² = c²

    D.h. wenn Du weisst wo Deine Figur hin animiert werden soll, dann kannst du ja berechnen wie weit diese nach X oder Y pro Tick bewegt werden darf.

    Angenommene Ausgangsposition:
    x = 50
    y= 50

    Zielposition:
    x=350
    y=250

    Dann musst du wissen wie groß der Weg zwischen diesen Punkten ist um eine gleichmäßige Bewegung hinzukriegen.
    (350 - 50)² + (250-50)² = c²
    90000 + 40000 = c²
    130000 = c²
    360,56 = c

    Also ist die zurückzulegende Strecke zwischen diesen beiden Punkten 360 Pixel. Wenn Du nun die Gesamtstrecke kennst, weisst Du auch wieviel davon pro "Tick" dann zurückgelegt werden dürfen. Das wäre jedenfalls ein Ansatz wie ich ihn machen würde.

    Wenn der Spieler die Figur aber ständig bewegt, ohne dass ein zu berechnender Zielpunkt vorliegt würde ich persönlich der einfachheit halber eine Geschwindigkeitsdämpfung mit einbringen bei der diagonalen Bewegung. Das hängt aber immer davon ab wie das am Ende dann wirklich aussehen soll.

    Ich weiss nicht ob meine Gedanken "to the point" sind, aber vielleicht ist das ja ein Ansatz. Wenn ich mir das C++ Beispiel (flüchtig) ansehe, dann wird die Rechnung dort genauso vorgenommen wie ich es beschrieben habe.

    Angenommen ich habe 360 Schritte errechnet die ich zurücklegen will. Jetzt startet Dein Timerevent und will eine Position weiter schieben.

    Angenommen er will Schritt 200 von 360 darstellen:

    Start:
    x = 50
    y= 50

    Zielposition:
    x=350
    y=250

    ((350-50)/360 * 200) + 50 = x
    ((250-50)/360 * 200) + 50 = y

    Ich teile den Weg durch die Gesamtanzahl Schritte und multipliziere mit dem aktuellen Schritt (hier 200). Das mache ich mit X und mit Y und dann habe ich die Koordinate, die ich zu diesem Event anzeigen will. Aber wenn es eine Klasse dazu gibt wie ErfinderDesRades schreibt, dann würde ich diese nutzen und mich nicht tot machen. Vorhandene Klassen haben auch den Vorteil dass diese weiter entwickelt werden und man davon profitieren kann.

    Ich weiss noch wie ich damals auf dem 680x0er Prozessor in Assembler mein ersten 3d Objekte berechnet und gedreht habe. Sinus, Cosinus Tabellen und Mathe waren Dein Freund - das braucht man heute zum Glück fast gar nicht mehr bei den Funktionen die einem geboten werden. Wenn möglich würde ich heute auch immer auf was fertiges zurückgreifen - nur halt verstehen warum etwas so oder so ist - aber dann das Rad nicht zweimal erfinden.