ImagesCollide() unter SDL ?!

durito

harryb schrieb:

hallo, ich bin von Dx/Blitzbasic unter Windows auf SDL/C unter Linux
umgestiegen!

Gratuliere Gleich drei Pluspunkte mit einem Streich

Ich weiss nicht, obs da ne fertige Funktion gibt. Aber sowas liesse sich ja auch von Hand machen, durch Abfragen der Farben der Pixel, welche für ne Kollision in Frage kommen.

PS: Pixelbasierte Kollision kann durchaus Sinn machen, je nach Anwendung..

rapso

TGGC schrieb:

Pixelgenaue Kollision ist IMHO Schwachsinn.

Bye, TGGC (Denken, und gut ist.)

verallgemeinerungen sind echt arm!

rapso->greets();

TGGC

rapso schrieb:

TGGC schrieb:

Pixelgenaue Kollision ist IMHO Schwachsinn.

Bye, TGGC (Denken, und gut ist.)

verallgemeinerungen sind echt arm!

Das ist aber auch 'ne Verallgemeinerung.

Bye, TGGC (Hast du's drauf?)

rapso

TGGC schrieb:

rapso schrieb:

TGGC schrieb:

Pixelgenaue Kollision ist IMHO Schwachsinn.
Bye, TGGC (Denken, und gut ist.)

verallgemeinerungen sind echt arm!

Das ist aber auch 'ne Verallgemeinerung.

Und es ist dir gleich aufgefallen, da siehst du welchen ranz du schreibst
rapso->greets();

TGGC

Ich sag ja nicht, das es Ranz ist (was auch immer genau das ist). In der Mathematik sind Verallgemeinerungen z.b. sehr nützlich.

Aber im Ernst, es wurde ja hier schon oft genug die Nachteile diskutiert.

Bye, TGGC (Dem beste BdT)

rapso

aber er will ja nicht vor und nachteile wissen bzw ob es gut ist oder nicht, das muss er sich ja schon überlegt haben bevor er die frage stellt, sonst wäre es ziemlich dumm von ihm (wenn er etwas unüberlegtes angeht).

@harryb(it)
wenn du die funktion nirgens findest, mußte sie wohl selbst implementieren

rapso->greets();

TGGC

rapso schrieb:

aber er will ja nicht vor und nachteile wissen bzw ob es gut ist oder nicht, das muss er sich ja schon überlegt haben bevor er die frage stellt, sonst wäre es ziemlich dumm von ihm (wenn er etwas unüberlegtes angeht).

*pfeif*

Bye, TGGC (Dem beste BdT)

harryb

Pixelgenaue Kollision ist IMHO Schwachsinn.

ok... aber mit der funktion imagescollide konnte ich einfach überprüfen
ob bild1 z.b: mit bild2 kollidiert. ich musste nicht die koordinaten angeben.
das war sehr praktisch da ich bild2 ja auch öfters haben will (feinde...)

also ich bin dann vieleicht nicht richtig "scharf" auf eine pixelgenaue
kollision... nur ich möchte es nicht selber mit koordinaten amchen müssen

gibt es da eine möglichkeit? ich hoffe ihr versteht was ich mein

danke!

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?

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?