PureBoard

Verfasst: **04.06.2018 22:32**

Der Delta-Wert ist dazu da, daß du später die Bewegungsgeschwindigkeit variabel gestalten willst, oder?
Bei meinem Pacman-Klon, den ich damals in Blitzbasic programmiert habe, hatte ich bei jedweder Geschwindigkeit immer eine konstante Schrittweite von 4 (teilbar durch die tileSize = 16), und die Geschwindigkeit habe ich stattdessen über ElapsedMilliseconds() zwischen jedem Schritt reguliert. Dann würden die ganzen Korrektur-Routinen wegfallen, da eine einzige Kollisions-Abfrage den Schlammassel bereits abfangen würde.
Vielleicht wäre das noch ein Lösungsansatz?
Mich hat man mal gelehrt, daß bei Performance-orientierten Routinen man Floats möglichst vermeiden, bzw. auf ein Minimum reduzieren sollte.

Verfasst: **04.06.2018 23:39**

Danke für die Beispiele mit den Einzelschritten das sieht gut aus

Werde trotzdem noch etwas weiter rumspielen.

Verfasst: **04.06.2018 23:42**

diceman hat geschrieben:Der Delta-Wert ist dazu da, daß du später die Bewegungsgeschwindigkeit variabel gestalten willst, oder?

DeltaTime brauche ich damit das Spiel überall gleich schnell läuft.
Das ist wichtig denn selbst mit v-Sync ist nicht garantiert das die Framerate überall gleich ist.

Verfasst: **05.06.2018 08:25**

Da ist kein ProcedureReturn #False am Ende von RectIntersect()? Ich weiß gerade nicht mehr wie PB das handhabt.

Wenn du die Achsen jeweils einfach nach außerhalb des Tiles korrigieren willst, dann hast du folgendes Problem:

Code: Alles auswählen

(die Boxen sind Wand-Tiles)
        +-----------+
        |           |
        |           |
        |           |
       Q| Y         |
        +-----------+
        | y         |
       X| M         |
       x|           |
   P    |           |
        +-----------+
        |           |
        |           |
        |           |
        |           |
        +-----------+

Willst du von P(layer) nach M(ove), dann würde durch die Kollision am Punkt M die X-Achse auf X gesetzt, und selbst mit Delta-Check pro Achse auch die Y-Achse auf Y, da die Bewegung P->M sowohl in X als auch Y verläuft. Zusammen wäre das dann Q. Selbst wenn du nach jeder Achsenkorrektur neu auf Kollision prüfst würdest du bei X oder Y landen, jenachdem welche Achse du zuerst prüfst bzw aus welcher Richtung du kommst. Außerdem würdest du im Falle von Y über die Frames hinweg zwischen Y und y festhängen/wechseln, oder ganz oben aus der Wand kommen. Eigentlich willst du ja nach klein x. Das geht mit Interpolation von P nach M, oder auch mit Schnittpunkt berechnen aber dazu bräuchest du erst wieder die richtige Außenkante des Wand-Tiles, in dem Fall die linke Außenkante des mittleren Wand-Tiles, die sich mit dem Weg P->M schneidet.

Verfasst: **05.06.2018 10:07**

Danke @#NULL der Post hat mit geholfen.

Hier mein aktueller Code - ist schon sehr nah dran

Nur ist die Bewegung in manche Richtungen nach der Kollision noch tlw. Eingeschränkt.

Code:

Code: Alles auswählen

If Abs(Level\Offset(X,Y)\X - Move\X) > Abs(Level\Offset(X,Y)\Y - Move\Y);MAX OVERLAP ON AXIS
  If Level\Offset(X,Y)\X + 8 > Move\X;GET OVERLAP DIRECTION & SET NEW POS
    Move\X = Level\Offset(X,Y)\X - 16
  Else
    Move\X = Level\Offset(X,Y)\X + 16
  EndIf
Else
  If Level\Offset(X,Y)\Y + 8 > Move\Y
    Move\Y = Level\Offset(X,Y)\Y - 16
  Else
    Move\Y = Level\Offset(X,Y)\Y + 16
  EndIf
EndIf

Das ist sehr wenig Code und die Kollisionen sind perfekt.

Jetzt gilt es die Bewegung in alle offenen Richtungen aufrecht zu erhalten.
Leider hab ich noch keine Idee wie

(Evtl. müssen die nächstliegenden Offset() Positionen mit berücksichtigt werden...)

PureBoard

Problem mit 2D Kollisionen

Re: Problem mit 2D Kollisionen

Re: Problem mit 2D Kollisionen

Re: Problem mit 2D Kollisionen

Re: Problem mit 2D Kollisionen

Re: Problem mit 2D Kollisionen