Zeige Ergebnis 1 bis 12 von 12
  1. #1
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4

    2d Collision detection tutorial

    http://www.harveycartel.org/metanet/...tutorialA.html

    is von den leuten, die das flashgame "N" gemacht haben. das tut is btw ganz nice bzw mehr als genug für die meisten 2d games.
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games


  2. #2
    Goddy3
    Gast
    Hey, das ist ziemlich nützlich.
    Aber ich mach eigentlich immer 'ne Bounding box. Wenn 2 kollidieren, test ich weiter auf pixelgenaue Kollision mittels Bit-Maske. Relativ schnell und effektiv

  3. #3
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4
    njo. was halt passt, ne? :>

    pixel akkurate kollisionen werd ich aber wohl nie benutzen... halt ich einfach für übertrieben bzw ich hab nicht vor nen game zu basteln, bei dem man soetwas überhaupt bemerken würde :>

    erst bb dann bitmask is schonmal gut. das drückt den aufwand schonmal erheblich runter. ansonsten gibbetz da noch andere tricks... zb so RLE style (geht aber nur bei konvexen gebilden).
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games

  4. #4
    edgewalker
    Gast
    Kollisionserkennung in 2D ist nicht weiter kompliziert. Die Bitmasken speichert man einfach in viel gröberer Auflösung als die Sprites und fertig.

  5. #5
    Goddy3
    Gast
    Original erstellt von oNyx
    njo. was halt passt, ne? :>

    pixel akkurate kollisionen werd ich aber wohl nie benutzen... halt ich einfach für übertrieben bzw ich hab nicht vor nen game zu basteln, bei dem man soetwas überhaupt bemerken würde :>

    erst bb dann bitmask is schonmal gut. das drückt den aufwand schonmal erheblich runter. ansonsten gibbetz da noch andere tricks... zb so RLE style (geht aber nur bei konvexen gebilden).
    Naja ... Manchmal ist es sehr praktisch. Sagen wir mal, du hast so eine Spielfigur

    **o**
    **o**
    **o**
    *ooo*
    ooooo

    Die Os stellen den Player, die Sternchen stellen ... nichts dar Wenn du einfach eine Bounding Box machst, kann es zu einer Fehlkollision kommen. Kann ärgerlich sein ... Aber eigentlich hast du recht. Meistens braucht man's nicht.

  6. #6
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4
    heh... wer sagt denn, dass ich eine bounding box nehmen würde? :>

    shoot em ups im "takumi flavor" (also quasi alle neueren shooter) benutzen zb ne 2x2 oder 1 pixel hit hitbox fürs eigene schiff und für die gegner bounding boxes.

    und die beispiel figur da... das könnte man auch mit nem rechteck und nem dreieck zusammensetzen... fertig.

    @edgewalker

    wenn die sachen rotieren wirds aber schon ätzend mit deiner methode :>
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games

  7. #7
    edgewalker
    Gast
    Naja, dafür hab sie auch nie verwendet. Aber das ist schon richtig.. wenn man anfängt, Sachen zu rotieren, sind nur Vektor-basierte Sachen zu gebrauchen.

  8. #8
    Goddy3
    Gast
    Hm ... kann man nicht bei rotierenden Objekten einfach einen Bounding-Circle (Hach, ich liebe das Wort "Bounding" ) drumlegen?

  9. #9
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4
    ja natürlich könnte man das machen. man könnte ja auch die rotation über animation regeln und dort die bitmask schiene fahren...

    aber sagen wir mal man macht n game mit kleinen autos... vogelperspektive... und man benutzt ne graphic api die nicht komplett zugestaubt is. wieso sollte man dann nicht richtig rotieren? :>

    k. in dem fall isses dann halt besser, wenn man das die hitbox des autos mit nem rechteck modeliert und dies entsprechned mitrotiert. es ist dann quasi auch pixelgenau (so +/- 1..2..3 pixelchen) und sehr schnell.

    in dem fall, dass kollisionen selterner sind als alles andere (normal halt ne). kann man natürlich auch ne bounding sphere vorschalten und im falle einer intersektion wird entsprechend rotiert und konkret gecheckt.
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games

  10. #10
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4
    von dem tutorial gibbetz mittlerweile nen zweiten teil...

    "Grid-Based Collision Detection and Raycasting"

    http://www.harveycartel.org/metanet/...tutorialB.html
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games

  11. #11
    Benutzerbild von oNyx
    Registriert seit
    Mai 2001
    Beiträge
    14.099
    Likes
    4
    um nochmal die aussage von edgewalker aufzugreifen...

    >Kollisionserkennung in 2D ist nicht weiter kompliziert. Die
    >Bitmasken speichert man einfach in viel gröberer Auflösung
    >als die Sprites und fertig.

    wenn das ganze tickbased is kann man das schon machen. wenn die animation unabhängig von der framerate is haut das natürlich kein stück mehr hin.

    auch is das erkennen von kollisionen nicht das ende der fahnenstange. also wenn man zb nicht will das die objekte einfach explodieren... oder zu ihrer ausgansposition zurückwandern etc... sobald man kollisionen lösen bzw physikalisch korret drauf reagieren muss, wird das ganze recht schnell sehr kompliziert.

    mehr details dazu zb hier:
    http://www.gamasutra.com/features/19991018/Gomez_1.htm

    selbst ein "einfaches" breakout game wird dann wirklich verdammt komplex. mit simplem bounds checken und richtung umdrehn isses da bei weitem nicht getan bzw diese vorgehensweise kann man komplett knicken. vektoren, planes und irgend nen integrationsschema müssen her.

    ich mach das zb momentan so, dass ich gugge zu welchem zeitpunkt ich die erste kollision hab. der richtungsvektor wird geändert (+sound und wassweissichwas) und dann wird der kollisionskrempel mit der restzeit nochmal durchlaufen... das geht solange bis ich am ende keine kollsion mehr finde bzw keine restzeit (für diesen frame) übrig ist. das ganze is sehr schnell (da ich den konkreten zeitpunkt der kollsion ermittle bzw ermitteln kann) und verdammt genau.

    die thematik ansich is imo schon ziemlich komplex aber glücklicherweise auch recht interessant. rigid body dynamics is zb ein verwandtes thema... also wenn man zb (so wie ich) ne einfache demo zusammengezimmert hat die hübsch rumintegriert aber nicht wirklich auf kollisionen reagiert (nur über constrains=boden/wände wie eis), dann kann man das ganze weitaus realistischer machen indem man gescheite kollisionserkennung einbaut und dann zb reibung über "penetration depth" nachäfft (zwar nicht sehr genau... sieht aber schon täuschend echt aus) [der fachausdruck is mir dafür jetzt leider entfallen].

    bei gamedev.net gibbetz btw auch noch nen batzen guter artikel und gamasutra.com hat natürlich auch noch mehr zu bieten (zb die artikel von jeff lander).

    ---

    hat zwar keine sau nach gefragt aber ich wolltes trotzdem mal gesagt haben :>
    弾幕 to the full extent of the jam!

    ze blog [rss] ☆ java game tutorialseee games

  12. #12
    ManDay
    Gast
    Danke, nützlich.

Forumregeln

  • Es ist dir nicht erlaubt, neue Themen zu verfassen.
  • Es ist dir nicht erlaubt, auf Beiträge zu antworten.
  • Es ist dir nicht erlaubt, Anhänge hochzuladen.
  • Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.
  •