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.
Problem mit 2D Kollisionen
Re: Problem mit 2D Kollisionen
Zuletzt geändert von diceman am 08.06.2018 09:34, insgesamt 1-mal geändert.
Now these points of data make a beautiful line,
And we're out of Beta, we're releasing on time.
And we're out of Beta, we're releasing on time.
Re: Problem mit 2D Kollisionen
Danke für die Beispiele mit den Einzelschritten das sieht gut aus
Werde trotzdem noch etwas weiter rumspielen.
Werde trotzdem noch etwas weiter rumspielen.
Re: Problem mit 2D Kollisionen
DeltaTime brauche ich damit das Spiel überall gleich schnell läuft.diceman hat geschrieben:Der Delta-Wert ist dazu da, daß du später die Bewegungsgeschwindigkeit variabel gestalten willst, oder?
Das ist wichtig denn selbst mit v-Sync ist nicht garantiert das die Framerate überall gleich ist.
Re: Problem mit 2D Kollisionen
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: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.
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 | |
+-----------+
| |
| |
| |
| |
+-----------+
Re: Problem mit 2D Kollisionen
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:
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...)
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
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...)