Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

Lerikson

Alter Hase

Beiträge: 412

Wohnort: nördlich von Hamburg

Beruf: Schüler

  • Private Nachricht senden

31

04.12.2009, 21:02

außerdem kann sowas jeder sagen, solange du seine code noch nicht gesehen hast ist es erstmal nur ne Beleidigung ;)

@drakon: ich hätte auch schon den ein oder anderen gebannt ;)
Errare est humanum. -Windows ist menschlich ;-)

KeksX

Community-Fossil

Beiträge: 2 107

Beruf: Game Designer

  • Private Nachricht senden

32

04.12.2009, 21:04

Ich habe den Fehler auch öfters. Es hängt mit der Geschwindigkeit zusammen.

Ich habe es bei mir getestet, die Ergebnisse waren immer:

Hohe Geschwindigkeit = Kollision wird zu früh berechnet
Niedrige Geschwindigkeit = Kollision wird rechtzeitig berechnet


Ich kann mir den Fehler leider nur nicht erklären..

33

04.12.2009, 21:12

Zitat von »"drakon"«

Zitat von »"zodX"«

Du programmierst wie ein Kind, ein kleines !!!
Kollidier doch einfach...


Hehe. Dachte ich auch. Da scheinst du Pech zu haben!
Mach dir wegen denen keine Gedanken. Einfach ignorieren. Das solche Leute so was posten hat weniger mit dir, als viel mehr mit deren mangelnder Sozialkompetenz und Unzulänglichkeit zu tun. ;)


Mir gehts ja nur darum das sowas find ich einfach bescheuert ist. So sehen es ein paar hier

C-/C++-Quelltext

1
2
3
4
if(Alter <= 12)
{
       Kann_nichts = true;
}

Aber das ist einfach nicht so

@drakon
Es geht hier ja eingentlich nicht um mich. Mich kotzt es einfach an das Leute hier reinkommen und nichts außer Müll hier rein schreiben.
Metal ist keine Musik sondern eine Religion.

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

34

04.12.2009, 21:16

Zitat von »"KeksX"«

Ich habe es bei mir getestet, die Ergebnisse waren immer:

Hohe Geschwindigkeit = Kollision wird zu früh berechnet
Niedrige Geschwindigkeit = Kollision wird rechtzeitig berechnet


Naja, jetzt mal aus der Hüfte geschossen:

Du berechnest in jedem Frame zunächst die Neue Position und dann die Kollision. Damit bekommst du dann:

Hohe Geschwindigkeit = Das Ding was du am Schirm siehst is noch an seiner alten Position, die neue Position (die du grad ausrechnest) ist aber schon so weit vorne dass Kollision stattfindet. Was tust du wenn Kollision auftritt? Vermutlich Ding in andere Richtung bewegen. Wenn du dabei von der alten Position ausgehst entspricht das was du zu sehen bekommst ziemlich genau dem dass es aussieht als würde es zu weit vorne kollidieren. Das liegt dann aber daran dass du das Ding an der Stelle wo es kollidiert wäre nicht mehr anzeigst sondern gleich umdrehst.

Niedrige Geschwindigkeit = Das Ding bewegt sich von Frame zu Frame nicht weit genug als dass das Problem auffallen würde.

Kollisionen immer nur an bestimmten Positionen in einem Frame zu betrachten führt unweigerlich zu Problemem. Z.B. wenn Geschwindigkeit viel zu hoch kanns passieren dass Dinge durch andere durchfliegen weil sie sich einfach von Frame zu Frame so weit bewegen dass du die Kollision dazwischen nicht mitbekommst. Um sowas zu beherrschen musst du dann nicht nur die aktuellen Positionen der Objekte in Betracht ziehen sondern die komplette Strecke die sie vom letzten Frame bis zum aktuellen zurückgelegt haben.

KeksX

Community-Fossil

Beiträge: 2 107

Beruf: Game Designer

  • Private Nachricht senden

35

04.12.2009, 22:23

Zitat von »"dot"«

Zitat von »"KeksX"«

Ich habe es bei mir getestet, die Ergebnisse waren immer:

Hohe Geschwindigkeit = Kollision wird zu früh berechnet
Niedrige Geschwindigkeit = Kollision wird rechtzeitig berechnet


Naja, jetzt mal aus der Hüfte geschossen:

Du berechnest in jedem Frame zunächst die Neue Position und dann die Kollision. Damit bekommst du dann:

Hohe Geschwindigkeit = Das Ding was du am Schirm siehst is noch an seiner alten Position, die neue Position (die du grad ausrechnest) ist aber schon so weit vorne dass Kollision stattfindet. Was tust du wenn Kollision auftritt? Vermutlich Ding in andere Richtung bewegen. Wenn du dabei von der alten Position ausgehst entspricht das was du zu sehen bekommst ziemlich genau dem dass es aussieht als würde es zu weit vorne kollidieren. Das liegt dann aber daran dass du das Ding an der Stelle wo es kollidiert wäre nicht mehr anzeigst sondern gleich umdrehst.

Niedrige Geschwindigkeit = Das Ding bewegt sich von Frame zu Frame nicht weit genug als dass das Problem auffallen würde.

Kollisionen immer nur an bestimmten Positionen in einem Frame zu betrachten führt unweigerlich zu Problemem. Z.B. wenn Geschwindigkeit viel zu hoch kanns passieren dass Dinge durch andere durchfliegen weil sie sich einfach von Frame zu Frame so weit bewegen dass du die Kollision dazwischen nicht mitbekommst. Um sowas zu beherrschen musst du dann nicht nur die aktuellen Positionen der Objekte in Betracht ziehen sondern die komplette Strecke die sie vom letzten Frame bis zum aktuellen zurückgelegt haben.


Das Problem tritt auch bei Kalistas Code auf. Also in der SDL und in der SFML. Von daher könnte man sagen dass es daran liegt. Die Frage ist nur: wie macht mans denn anders?


Und außerdem geht es ja net um mein Problem sondern um das des Threaderstellers, wollte nur ne Möglichkeit geben, woran es liegen könnte xD.

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

36

04.12.2009, 22:28

Du musst die Verbindung zwischen den Frames mit einbeziehen. Das heisst, wenn ein Ball in einem Frame an Position (0,0) ist und im nächsten (100,100), dann prüfst du logischerweise nicht die Kollision bei (100,100), sondern die gesamte Strecke von (0,0) bis (100,100). (Lässt also einen ganzen Korridor auf Kollision prüfen).

37

10.12.2009, 12:09

Schau: ganz einfach, der zurückgelegte Weg ist ein Viereck ( kein Quadrat, kein Rechteck !! ).
Ist das Kollissionsobjekt im Viereck ? Wenn ja schick mich nach Hause.

Kennst du sowas wie Linesegment per Linesegment Intersection ??
Oder willst du lieber das Jordan Theorem ??

Wenn nicht, so viel Glück auf Eurem weiteren Lebensweg !!



(P.S.: Ausserdem hast Du später zwei Vierecke !!
Oder spielst Du lieber mit dem Timer ?)

38

10.12.2009, 13:36

Hier eines von vielen Beispielen, um die Du ganz einfach nicht herumkommen wirst leider:


// public domain function by Darel Rex Finley, 2006



// Determines the intersection point of the line defined by points A and B with the
// line defined by points C and D.
//
// Returns YES if the intersection point was found, and stores that point in X,Y.
// Returns NO if there is no determinable intersection point, in which case X,Y will
// be unmodified.

bool lineIntersection(
double Ax, double Ay,
double Bx, double By,
double Cx, double Cy,
double Dx, double Dy,
double *X, double *Y) {

double distAB, theCos, theSin, newX, ABpos ;

// Fail if either line is undefined.
if (Ax==Bx && Ay==By || Cx==Dx && Cy==Dy) return NO;

// (1) Translate the system so that point A is on the origin.
Bx-=Ax; By-=Ay;
Cx-=Ax; Cy-=Ay;
Dx-=Ax; Dy-=Ay;

// Discover the length of segment A-B.
distAB=sqrt(Bx*Bx+By*By);

// (2) Rotate the system so that point B is on the positive X axis.
theCos=Bx/distAB;
theSin=By/distAB;
newX=Cx*theCos+Cy*theSin;
Cy =Cy*theCos-Cx*theSin; Cx=newX;
newX=Dx*theCos+Dy*theSin;
Dy =Dy*theCos-Dx*theSin; Dx=newX;

// Fail if the lines are parallel.
if (Cy==Dy) return NO;

// (3) Discover the position of the intersection point along line A-B.
ABpos=Dx+(Cx-Dx)*Dy/(Dy-Cy);

// (4) Apply the discovered position to line A-B in the original coordinate system.
*X=Ax+ABpos*theCos;
*Y=Ay+ABpos*theSin;

// Success.
return YES; }

If you need to find out only when (and where) the line segments intersect, you can modify the function as follows:
// public domain function by Darel Rex Finley, 2006



// Determines the intersection point of the line segment defined by points A and B
// with the line segment defined by points C and D.
//
// Returns YES if the intersection point was found, and stores that point in X,Y.
// Returns NO if there is no determinable intersection point, in which case X,Y will
// be unmodified.

bool lineSegmentIntersection(
double Ax, double Ay,
double Bx, double By,
double Cx, double Cy,
double Dx, double Dy,
double *X, double *Y) {

double distAB, theCos, theSin, newX, ABpos ;

// Fail if either line segment is zero-length.
if (Ax==Bx && Ay==By || Cx==Dx && Cy==Dy) return NO;

// Fail if the segments share an end-point.
if (Ax==Cx && Ay==Cy || Bx==Cx && By==Cy
|| Ax==Dx && Ay==Dy || Bx==Dx && By==Dy) {
return NO; }

// (1) Translate the system so that point A is on the origin.
Bx-=Ax; By-=Ay;
Cx-=Ax; Cy-=Ay;
Dx-=Ax; Dy-=Ay;

// Discover the length of segment A-B.
distAB=sqrt(Bx*Bx+By*By);

// (2) Rotate the system so that point B is on the positive X axis.
theCos=Bx/distAB;
theSin=By/distAB;
newX=Cx*theCos+Cy*theSin;
Cy =Cy*theCos-Cx*theSin; Cx=newX;
newX=Dx*theCos+Dy*theSin;
Dy =Dy*theCos-Dx*theSin; Dx=newX;

// Fail if segment C-D doesn't cross line A-B.
if (Cy<0. && Dy<0. || Cy>=0. && Dy>=0.) return NO;

// (3) Discover the position of the intersection point along line A-B.
ABpos=Dx+(Cx-Dx)*Dy/(Dy-Cy);

// Fail if segment C-D crosses line A-B outside of segment A-B.
if (ABpos<0. || ABpos>distAB) return NO;

// (4) Apply the discovered position to line A-B in the original coordinate system.
*X=Ax+ABpos*theCos;
*Y=Ay+ABpos*theSin;

// Success.
return YES; }


...und bitte nocheinmal: Ich brauch mein Textkäs-chen !!! Bitte, bitte...

drakon

Supermoderator

Beiträge: 6 513

Wohnort: Schweiz

Beruf: Entrepreneur

  • Private Nachricht senden

39

10.12.2009, 14:35

zodX. Benutzt du die Codetags aus Prinzip nicht, oder hast du die nocht nicht gesehen?

40

10.12.2009, 18:08

Kommt ganz auf den Fall an.

Werbeanzeige