Kolisionsabfrage mit sprite3d?

[estate]

Hallo

Vielleicht kann mir jemand bei meinem kleinen Problem helfen:

Ich bin gerade bei einem horizontal scrollenden shooter, und möchte das Raumschiff mit einem Sprite3d realisieren. (wegen der Rotation)
die landschaft besteht aber aus transparenten sprites.
Deshalb suche ich eine Möglichkeit die Kollision zu berechnen

Danke im Vorraus

[SirCus]

ist das problem der transparente sprite oder das Sprite3D? in letzterem falle machst du ein einfaches Sprite, welches nicht 3D ist, und lässt das an der stelle kollidieren wo sich das sprite3D befindet.
aber anzeigen tust du nur das sprite3D.

also
DisplaySprite3D(#raumschiff3D, x,y)
SpriteCollision(#raumschiff2D,x,y,#Landschaft,lx,ly)

[dllfreak2001]

Ich glaube estate will das raumschiff ja drehen dann sehe es unnatürlich aus wenn die kollision auf das Shiff trifft als ob es gerade stehen würde.
Ich wüßte jetzt auch nicht was man da direkt machen sollte.

[Robert Wünsche]

Ich hätte hier eine einfache theorie (theorie deshalb, weil ich nicht weis, ob es wirklich funktioniert und wie viel zeit es wegnimmt):

Die kollision soll negenbei berechnet werden ? --> ja
Die kollision soll pixelgenau sein? --> ja

-->
Zuerst wird ein bild mit "masken(sind sprite3d's, die eine farbe haben, wo sie kolidieren können und transparent sind, wo sie nicht kolidieren sollen)" der objekte gerendert, dabe wird das raumschiff zuletzt in einer anderen kolisionsfarbe als die anderen objekte gerendert.

In diesem beispiel wird das raumschiff weis und halbdurchsichtig und die anderen objekte rot.
Der hintergrund ist schwarz.

Danach muss nur noch der farbwert in der nähe des raumschiffes ausgewertet werden und dann weis man, wo es wie kolidiert.
wo schwarz ist --> nichts kolidiert
wo graulich ist --> nichts kolidiert
wo rot ist --> nichts kolidiert
wo was dazwischen(etwa rgb:125...254,125,125) ist --> kolidiert !

(bei dieser methode muss antialiasing aus sein und die sprite3d texturen dürfen nicht gefiltert werden).

Dann wird der bildschirm gelöscht und das richtige bild gerendert.

Wie gesagt, ist blos ne idee.....

[Lars]

Am einfachsten ist wohl, eine "Kreis-Kollision" zu bauen. Die ist nicht
pixelgenau, aber reicht oft.

Code: Alles auswählen

Sprite3D_1_Radius.f = Sqr(Pow(SpriteWidth(#Das_Ursprungs_2D_Sprite), 2) + Pow(SpriteHeight(#Das_Ursprungs_2D_Sprite), 2))

Punkt.POINT 

Repeat
  ;MainLoop
  ;Kollision mit einem Punkt
  If Sqr(Pow(Punkt\x - Sprite3D_1_Pos\x, 2) + Pow(Punkt\y - Sprite3D_1_Pos\y, 2)) <= Sprite3D_1_Radius
    ;Kollision = #True
  EndIf
  ;Kollision mit einem anderen Sprite3D
  If Sqr(Pow(Sprite3D_2_Pos\x - Sprite3D_1_Pos\x, 2) + Pow(Sprite3D_2_Pos\y - Sprite3D_1_Pos\y, 2)) <= Sprite3D_1_Radius + Sprite3D_2_Radius
    ;Kollision = #True
  EndIf
ForEver

[PMV]

In Lars fall müsste das Raumschiff aber ne ründliche Form haben, damit das ganze nicht zu ungenau wird. Das sieht man ja am AI-Game. Dort dürfte doch die selbe Roution genommen worden sein, oder? Die Bots können sich sogar verkeilen, dies wäre in einem Aktionreichen Arcadegame nicht sehr wünschenswert , allerdins ist das eine schnelle möglichkeit.

Erst mal sei gefragt, ob SpritePixelCollision(#Sprite1, x1, y1, #Sprite2, x2, y2) nicht sogar mit dem rotierten 3d Sprite arbeitet? Ich hab schon länger nicht mehr mit gearbeitet, und das komplet austesten wäre jetzt was langvierig -_-, aber wenn das so wäre müssteste nur das 3D Sprite vorher rotieren und dann die Collisionsabfrage machen.

So und dann hätte da noch ne andere Idee, welche wahrscheinlich änlich wäre wie die von Wünsche, aber vermutlich was schneller. Allerdings hab ich das bis jetzt noch nie ausprobiert.

Mach doch aus dem Rotierten Sprite ein normales Sprite. Dafür müssteste lediglich das rotierte 3D Sprite in ein "normales" Sprite kopieren. Eine möglichkeit die mir dazu einfällt, wäre das 3D Sprite rotiert in den Screenbuffer zu schreiben. Diesen dann mit GrabSprite(#Sprite, x, y, Breite, Höhe [, Modus]) in einem neuen Sprite speichern und dieses für die Kollision verwenden. Da das ganze natürlich Pixel genau sein soll müssteste noch die gewollte Farbe vorher als Transparent Definieren und dann mit SpritePixelCollision(#Sprite1, x1, y1, #Sprite2, x2, y2) das ganze überprüfen.

MFG PMV

[Lars]

Erst mal sei gefragt, ob SpritePixelCollision(#Sprite1, x1, y1, #Sprite2, x2, y2) nicht sogar mit dem rotierten 3d Sprite arbeitet?

Tut es nicht.


Deine zweite Idee dürfte viel zu langsam sein, erst in de Screen rendern,
dann grabben und dann vergleichen.


Im AI Game verwende ich diese Methode, und ich finde, sie ist nicht die
schlechteste, mir ist noch keine Kollision aufgefallen, die völlig
unberechtigt wäre

[PMV]

Ich vermute auch das meine zu lansam ist, aber so in etwa müsste es gemacht werden, um eine 100% genaue Kollisionserkennung zu erhalten. Zu dem gibt es ja bestimmt mehr möglichkeiten, als wie ich beschrieben hab.

Zu deiner Roution, unberechtigt sind die Kolisionen da nie, das ist richtig, aber mir ist schon heufieger passiert, das z.b. wenn die Bots in einander fahren, die nicht mehr voneinander los kommen. Manchma gehts allerdings auch. Aber gut ist die roution alle mal, vielleicht rechts auch für ein Arcade Game, aber eben nicht immer. Und dann muss halt etwas genaueres und Rechenintensieveres her halten. Aber vielleicht fällt ja irgend wem noch was ganz anderes ein, was die retung wäre ... für mich wäre das nämlich auch nicht schlecht, dann müsste ich nicht, wenns so weit ist, wochen lang eine geeigente Methode finden und es gibt mit sicherheit auch noch viel mehr, denen so was gelegen kommt.

MFG PMV

[Mereep]

Hab jetzt keinen Bock mir ne richtige Routine einfallen zu lassen, aber vielleicht mal ein Denkanstoß:
Man könnte doch den Bildschirm intern in rel. kleine Kästchen einteilen
und für die Objekte, für die ne Kollision möglich is wie ne kleine Matrix anlegen, und dann prüfen, ob sich auf einem Kästchen mehrere Punkte treffen würden. Währe ziemlich genau und schnell(sicher schneller als SpritePixelCollision) bloß eben ein wenig aufwändig ^^
Egal, nur n Vorschlag, der mir grade so durch den Kopf ging!

GreeZ Mereep

[estate]

Eigentlich handelt es sich mehr um ein Flugzeug, als um ein Raumschiff,
Deshalb sollte die Routine schon annähernd pixelgenau sein, und trotzdem nicht zu viele Resourcen verbrauchen.