ImagesCollide() unter SDL ?!

durito

hm?

Wie denn "ohne Koordinaten"? Wenn Du von dem Objekt ein Bild auf (x/y) positionieren kannst, dann kannst ja auch noch rasch auf Kollision prüfen?

rapso

nur ich möchte es nicht selber mit koordinaten amchen müssen

das heißt, es eine funktion gibt die das mit coordinaten macht wäre das ok und wenn du etwas eincoden müßtest, hauptsache nicht mit coordinaten, wäre das auch ok?

rapso->greets();

harryb

ne also eine pixelgenaue kollision brauche ich dann nicht!
ok dann werde ich mich mal mit koordinaten prüfen müssen...

nur ich hatte mir es halt so gedacht das ich einfach ein hintergrundbild
als level nehmen kann... überall wo schwarz ist kommt das bild(meine spielfigur)
durch, überall anders halt nicht... so wärs einfach gewesen...

nun müsste ich das ja wenn ich alles mit den koordinaten überprüfen muss
anders machen... hättet ihr da vieleicht einen kleinen tipp für mich?

wäre sehr nett! danke!

p.s:

Bist du jetzt scharf drauf, oder nicht? Falls nicht, dann würde ich ein regelmäßiges Polygon um die Objekte legen, z.B. ein Quadrat.
Wieso muss es denn so fürchterlich genau sein?

und was hat das mit den Polygonen genau auf sich?

und was hat das mit den Polygonen genau auf sich?

Polygon heißt "Vieleck" (griechisch: poly = viele)
Beispiel für ein Polygon: Hexagon (Sechseck).

Was es damit auf sich hat? Bei regelmäßigen Polygonen (also alle Seiten gleich lang) als BoundingBox lässt sich relativ leicht berechnen, ob zwei Objekte sich schneiden.

harryb

ok also das hört sich gut und praktisch an.
habt ihr oder du vieleicht ein kleines tutorial bereit wo der umgang
damit erklärt wird?

denn davon habe ich nicht so richtig ahnung!

aber vielen danke schonmal!!

leech

schau dich doch mal hier um.... vielleicht findest du da was....
http://www.gamedev.net/reference/list.asp?categoryid=45#99

dieser artikel scheint nicht schlecht zu sein.... habe ihn aber nur überflogen...
http://www.gamedev.net/reference/articles/article735.asp

fletscher

hmmm

wie macht man das am besten unter SDL?

z.b. ich habe

ein flieger, dann noch 5 feindflieger und die geschosse von denen und meine eigenen.
ist da nicht die pixelgenaue collision von vorteil? oder bei beat n ups.

da ist es unter BB ( blitzbasic ) recht einfach.

wie gehst das unter SDL? wie würdet ihr das machen.

ihr habt euren flieger dann noch 5 gegner und dann sind dann noch 50 geschosse drauf. jetzt müsst ihr ja ständig überprüfen ob

a eurer flieger mit anderm flieger collidiert
b eurer flieger mit den geschossen der anderen collidiert
c die anderen flieger mit euren geschossen collidieren

EDIT: Bei Streetfigher möchte ich ja auch wirklich erst den gegner treffen, wenn ich ihn wirklich treffe. oder bei anderen shooter, wo man "scracht" sprich dicht an den gegnergeschossen fliegt ist man in einer "gefahrenzone" und wird mit mehr punkten belohnt. da geht ziemlich viel ab auf dem bildschirm und das noch superflüssig.

TGGC

fletscher schrieb:

ist da nicht die pixelgenaue collision von vorteil?

Warum?

Wenn die Genauigkeit einer großen AABB nicht reicht, macht man eben mehrere kleinere.

Bye, TGGC (Dem beste BdT)

fletscher

hmmm also ok
die deutsche sprache ist bissle verschwommen zum formulieren von fragen

also ich sags mal so

das gegenteil von pixelgenaue collision ist ja dann die pixelUNgenaue collision.

Ungenau hört sich nach "pfusch" an. Also wie meint ihr dann das gegenteil?

Also ich habe z.b. ein quadrat. 128*128 Pixel. Darin hab ich meinen Flieger gezeichnet. die ausfüllfarbe ist eine die naher nicht angezeigt wird. jetzt möchte ich ja das wenn das geschoss ( auch quadrat 20*20 das auch die "neutrale" farbe hat ) die "äusseren" pixel davon auf meinen flieger "äusseren" pixel, trifft, soll ich "sterben".

da ruf ich einfach die Funktion auf und gut ist.
Wie würdest du das dann machen. also jetzt nicht in einem satz antworten, sondern in einer art algorithmus. damit ich mir die "pixelUNgenaue collision" mir besser vorstellen kann. maybe sehe ich da den vorteil und versuche ihn zu nutzen.

geloescht

man kann einfach mehrere boundingboxen pro sprite specihern, wenn es eine ungewöhnliche form hat, die nicht gut in eine einzige box passt. dann ist es eine kollision, wenn irgendeine box von sprite A sich mit einer box von sprite B schneidet.
geloescht

fletscher

ok also ich hab die 128*128 und mach dann "intern" 100*100 drauf. das ist deine "bounding-box"

was ist der vorteil? geschwindigkeit? ich meine es wäre doch nicht schlecht wenn es bei SDL einfach ne funktion gäbe die das alles abcheckt und ich mich darum kümmern müsste. wenn ich ein einfaches Game mache, und ich als mindes. voraussetzung 1400mhz angebe, müsste es doch nicht bemerkbar sein, das es langsamer ist als das "bounding-box-prinzip"
gibt es da erfahrungswerte? Ist es gleich um Faktor 5 oder wie?

TGGC

Hmm, ne Kollisionsabrage zwischen zwei AABBs schreibt man vermutlisch schneller, als dies Posts in diesem Board...

Bye, TGGC (Dem beste BdT)

fletscher

TGGC - sorry, aber diesmal will ich dich echt was bitte.
Kannst du dir bitte in Zukunft post auf meine Fragen ersparen?

Ne im Ernst. Sogar wenn du der einzige in diesem Forum bist der mit helfen kann, bitte behalts für dich.

Soll kein Angriff auf deine Person sein, aber ich will einfach deine comments nicht lesen. Wenn du das gleiche wünscht, dann poste ich auch nichts mehr für/über dich.

Danke

TGGC

fletscher schrieb:

ich will einfach deine comments nicht lesen.

Dann lies sie eben nicht.

Bye, TGGC (Dem beste BdT)

Sgt. Nukem

Vorteile:

Kollision hängt nicht von der Auflösung ab (1024x768, 1280x1024, 1600x1200, ...)
Schnitte zwischen Rechtecken sind viel einfacher zu berechnen als pixelgenaues Austesten
Dazu kommt noch, daß das Locken ("Sperren") des Grafik-RAMs zum Holen der Pixel enorme Zeit verschlingt