spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Aber warum sollte man etwas verstehen, was man in der Praxis nicht verwenden sollte? Pixelperfekte Kollision wird bei höheren Auflösungen langsamer (da mehr Pixel betrachtet werden müssen), bei Animationen ändert sich das Verhalten von Kollisionen (da Objekte sich verformen können), Rotationen sorgen für Probleme, es lässt sich nicht auf den 3D-Bereich übertragen usw. Ich hatte schonmal ein Beispiel für ein J2ME (ja, das alte Java für Mobilgeräte) gesehen, bei dem pixelgenaue Kollision verwendet wurde, bei der der Spieler sehr leicht an allen möglichen Objekten hängen bleiben konnte, nur weil er nicht mehr zur Seite, sondern hoch laufen wollte. (Die Spielfigur war breiter als hoch, dadurch geriet der Arm in den Busch, die Wand, ...)
Weiterhin betrachtet ein Mensch die auf dem Bildschirm angezeigten Dinge nicht als Ansammlung von viereckigen Kästen, sondern versucht diese auf möglichst einfache Grundformen herunterzubrechen. Warum sollte sich ein Spiel dann anders verhalten?
Wie du dir vielleicht denken kannst, finde ich nicht, dass pixelgenaue Kollisionen sinnvoll investierte Zeit wäre.

Warum sich mit den alten Griechen beschäftigen, wenn die eh schon tot sind?
Wenns interessant ist, ist es doch gut.

Das Problem an diesem Vergleich ist: "die alten Griechen" ist extrem weit gefasst und umfasst unter anderem auch die Philosophen dieser Zeit, die sich mit grundlegenden Prinzipien beschäftigt haben, welche nicht an Gültigkeit verloren haben. Weiterhin war in dieser Zeit ein bestimmter Stil in der Kunst sehr verbreitet, und ich denke die Gebiete der Mathematik und Architektur sind ebenfalls davon betroffen.
Bei pixelgenauer Kollision bezweifle ich, dass das jemals eine sinnvolle Überlegung war.

Wenn du eine pixelgenaue Kollision schreibst dann ist wichtig was TGGC und David gesagt haben. Pixel können nicht rotiert sein und Texturefilterung darf nicht vorhanden sein. Am einfachsten ist es wenn du die einzelnen Sprites so renderst wie sie sind. Das heißt du darfst sie verschieben, nicht aber skalieren oder rotieren. Möchtest du ein Objekt rotieren so legst du dafür verschiedene Grafiken im voraus an. Möchtest du jetzt überprüfen ob zwei Sprites miteinander überlappen guckst du welche Pixel der beiden Grafiken im Spiel überlappen. Diese sich überlappenden Pixel gehst du durch und guckst ob an einem Punkt beide Pixel sichtbar, das heißt nicht transparent sind.
Das ist zumindest der einfachste Fall. Möchtest du Grafiken auch wirklich rotieren und skalieren können, so müsstest du für rotierte und/oder skalierte Grafiken die Zielgrafik bestimmen, das bedeutet die Grafik wie sie nach der transformation aussieht. Mit diesen Grafiken kannst du dann wie vorher auch wieder auf Überlappungen prüfen und danach die jeweiligen Pixel durchgehen.

Zitat von »Sacaldur«

In einem anderen, ähnlichen Thema habe ich eine solche Antwort bereits gegeben:

Zitat von »Sacaldur«

Statt einer "pixelgenauen Prüfung" solltest du die Formen deiner Objekte lieber mit geometrischen Formen (Rechtecke und Kreise) annähern [...] und auf Überlappung dieser prüfen.

Also grob formuliert: genau das, was sonst jede Physik-Engine machen würde. (Geometrie und darauf basierende Berechnungen.)

Ja. Du musst das aber nicht selber überprüfen, das macht ja die Physik-Engine für dich.