Mir wäre dies neu. In welcher Engine ist dass denn so gelöst bzw. wo hast du das gehört?

Es stimmt zwar dass durch die einführung von GPU compute fähigkeiten in modernen GPUs die Anwendungsmöglichkeiten dieser auch in andere Bereiche übergehen können (simple Physik simulation für z.B: Partikeleffekte),
für normale Kollissionserkennung verwendet man aber weiterhin die CPU. (u.a. weil die Kollissionserkennung viele Branches in der Logik haben kann die GPUs garnicht mögen, es limitationen bei der Art wie Informationen an die GPU gesendet/wie diese gelesen werden gibt, etc... Zudem hast du weitere Probleme wie die verringerte GPU leistung durch weitere nicht-grafische kalkulationen und erhöhte Speicherbandbreite.)

Jein. Wenn du GMS2 verwendest wirst du DX11 als Render backend verwenden. Wenn du geschickt bist und dich mit DX11/GPU compute/C++/DLLs auskennst wirst du evtl irgendetwas lauffähiges auf die Beine stellen können. (Ob die implementierung überhaupt praktisch ohne größere hürden/probleme verwendbar wäre sei mal dahingestellt.)

Nativ ist dies aber im GM (meines Wissens nach) nicht möglich.


Ja, du kannst sowas zwar machen (verwende einen Shader der 2 Masken als Input annimmt und dir den output in eine weitere Textur schreibt), das Problem allerdings hier ist dass du die Informationen aus der Textur auf CPU seite auslesen musst. Du wirst also konstant den GPU memory bus mit zusätzlicher Speicherbandbreite beanspruchen was sich negativ auf deine GPU performance ausüben wird.

Zudem bist du im Falle eines normalen Shaders im bezug die Ausgabemöglichkeit solcher informationen im GM limitiert. Im Falle eines Shaders der die überlappung 2er masken ausgibt würdest du z.B: eine Textur rausbekommen wo jeder Pixel bei dem eine Überlappung stattfinden würde schwarz eingefärbt wäre und der Rest weiß.

Die CPU müsste nun die Textur von der GPU über den Bus auslesen und durch jeden Pixel durchiterieren um zu schauen ob einer von denen schwarz eingefärbt ist oder nicht.

Das ist verdammt ineffizient und zahlt sich wirklich nicht aus.

/Edit: Es wäre erwehnenswert dass die oben beschriebene Methode zwar kein GPU compute benötigt, aber eben verdammt ineffizient ist.

Hmm also in 3d wird (immer) öfters raytracing verwendet. Das was du da meinst mit der Maske klingt zwar ganz toll, da sehe ich aber auch ein Problem, was ist wenn da was dynamisch ist, dann musst du dein surface order was auch immer neu malen. Ich sehe auch definitiv keinen Grund warum du sowas suchst, bist du schon an die Grenzen der Engine gestoßen? Wenns dir um sowas wie tile collisions geht, wieso erstellst du nicht einfach ein Grid und füllst es mit 1 für Wand und 0 für Luft?
Wenns wirklich die GPU sein muss dann kannst du wohl Vertexkoordinaten als collision mesh benutzen, sowas hab ich schonmal gemacht und war recht vielversprechend, allerdings ohne GPU pille palle.
Soll jetzt nicht böse aufgefasst werden aber anstatt seit Wochen rumzujammern über collisions wieso setzt du dich nicht einfach dran und probierst dich mal aus. Man kann quasi alles machen mit dem GM, und vieles sogar effizient. Ich hab einfach das Gefühl du zerbrichst dir den Kopf über Probleme die eigentlich keine sein sollten. Auch ich als langjähriger GM user lerne jeden Tag noch was dazu, manchmal sieht man die einfache bessere Lösung neben der komplizierten nicht.

Da würde ich wie zu beginn gesagt gerne irgendein Beispiel haben.
Physik basierte simulationen wurden überwiegend auf der CPU berechnet. Natürlich stimmt es dass durch die moderneren GPUs solche simulationen in bestimmten Fällen auf den Grafikprozessor ausgelagert werden können (mit Restriktionen), aber dies sind eher Ausnahmen als die Regel.


Ich bin das Paper mal schnell durchgeflogen. Die scheinen da einfache Rasterization mit einem Stencil buffer zu verwenden weshalb dies selbst auf einer Geforce 5 zu laufen scheint.
(Allerdings k.a. wie die die Ergebnisse zur CPU senden.)

Aber selbst da gleich zu beginn auf der ersten Seite unter "Introduction" zeigen die die Limitationen ihrer technick auf:

- Erhöhte Speicherbandbreite (degradation der GPU performance)
- Nur "abgeschlossene" Objekte ohne lücken. (Ein Rechteck wo eine Seite fehlt funktioniert hingegen nicht. Ein singler Triangle-Triangle check geht auch nicht)
- Pro Kollissionscheck können nur 2 Objekte überprüft werden. (es können keine riesigen Welten auf einmal überprüft werden.)

Dies in kombination mit der Tatsache dass deine GPU ressourcen für die eigentliche Grafische berechnungen reduziert werden, macht es schwer diese Methode zu empfehlen.


Das ist eben aber nicht "einfach so" möglich. Die GPU spuckt dir mit traditioneller Rasterisierung nicht einfach einen true/false wert zurück ob was überlappt oder nicht.
Im GM wirst du an die traditionellen Rendering methoden gebunden sein. Sprich: Render eine differenzmaske aus 2 input texturen mit einem Shader die dann von der CPU pixel für Pixel ausgelesen wird.

Mit Compute Shadern wird man mehr möglichkeiten was dies anbelangt haben, aber selbst da hat man limitationen die man beachten muss. (die CPU ist da wesentlich flexibler.)

Kommt darauf an was du unter "alt" verstehst. Wenn du richtig alte Spiele (Amiga z.B) meinst, musst du bedenken dass damals die Hardware doch anders funktionierte als heute. Es gab z.B: keine dedizierte GPU/GPUram.
Du konntest mit der CPU direkt in den Speicher schreiben welcher dann direkt vom Bildschirm gelesen und angezeigt wurde.
Bei sowas wirst du natürlich spezifische Tricks anwenden können die aber mit der heutiger Hardware inkompatibel sind.

meine "two cents" - passend zum Thema, aber andere herangehensweise (Surfaces statt Shader):