• 6Minuten
blank

Workflow

Das waren nun viele Informationen. Bevor wir nun endlich mit dem Code loslegen, möchte ich das Vorgehen zusammenfassen.

Zunächst brauchen wir natürlich einen Raum. Wenn wir eine Figur haben, dem der Betrachter folgen sollte, müssen wir erst eine Kamera mit entsprechender View einrichten.

Für die Post-Processing-Shader verwenden wir eigene Objekte. Um den Überblick zu bewahren, hat es sich bewährt, einen eigenen Layer mit der Bezeichnung Shader im Raum anzulegen. Außerdem stellen wir bei den Raumeinstellungen einen View ein.

GMS View Einstellungen
Beispiel für View-Einstellungen in GameMaker Studio 2

Bei Post-Processing-Effekten arbeiten wir mit dem Draw-GUI-Event. Außerdem erzeugen wir eine eigene Oberfläche, welche der Bildschirmgröße bzw. dem View-Port entspricht.

Es ist sowohl möglich, für jeden Shader ein Objekt zu erzeugen, oder ein Objekt, in dem sich alle Post-Processing-Shader befinden. In diesem Fall kann bspw. auf Tastendruck umgeschaltet werden. Beide Vorgehensweisen haben Vor- und Nachteile.

Praxistipp – Umgang mit Variablen

Wenn man einen Shader programmiert, möchte man häufig Variablen verwenden, um bspw. die perfekten Werte zu finden. In der Praxis hat es sich bewehrt, entsprechende Tasten einzurichten, mit denen man die Werte im Spiel verstellen kann. Das geht wesentlich schneller als Wert zu definieren, Spiel kompilieren und starten, Spiel abbrechen, Wert verändern u. s. w.

Wenn man nur einen Wert hat, finde ich das Mausrad sehr praktisch. Indem man hoch und runter dreht, verschiebt man den Wert. Natürlich ist es dabei sinnvoll, den entsprechenden Wert auf dem Bildschirm anzuzeigen.

Sobald man die perfekten Werte gefunden hat, kann man sie fest eingeben und die Steuerung des Shaders auskommentieren.

Vorsichtsmaßnahmen

Es gibt vor allem zwei Abfragen, die wichtig sind, bevor man einen entsprechenden Shader einsetzt:

  1. Existiert die Oberfläche?
  2. Wurde der Shader kompiliert?

Wie bereits erwähnt, sind Oberflächen flüchtig. Deshalb müssen wir im Draw-GUI-Event als erstes fragen, ob das Surface existiert. Wenn nicht, legen wir es neu an.

Mit surface_exists() prüfen wir, ob die angegebene Oberfläche surf existiert. Mit dem Ausrufezeichen drehen wir die Frage um, was so viel bedeutet wie: Wenn die Oberfläche surf nicht existiert, dann…

Mit surface_create() legen wir in dem Fall die Oberfläche neu an. Das sollte sich ganz oben im Draw-GUI-Event befinden, damit wir immer sicherstellen, dass wir auf surf zeichnen können. Zu resX und resY komme ich später.

Ob der Shader kompiliert wurde, habe ich im ersten Tutorial bewusst nicht abgefragt, ist aber sinnvoll. Dies können wir mit shader_is_compiled() tun. Beispiele dafür sehen wir nachher noch zur Genüge.

Shader-Objekt

Für alle nachfolgenden Shader ist der Aufbau des Objekts identisch. Unterschiede gibt es lediglich beim Namen des Shaders und die verwendeten Variablen. Das bedeutet, dass ich hier nur einmal den ganzen Aufbau erkläre. Bei den weiteren Beispielen gehe ich nur auf die Unterschiede ein.

Create-Event

Wie oben im Screenshot gezeigt, nutzen wir View-Port 0. Entsprechend lesen wir in den ersten beiden Zeilen die horizontale und vertikale Auflösung aus.

In der letzten Zeile legen wir die Oberfläche mit -1 an. Der Rest geschieht im Draw-GUI-Event.

Draw GUI

Die ersten Zeilen kennen wir bereits. Mit view_set_surface_id() legen wir den Inhalt fest, auf das eine Oberfläche gezeichnet werden soll. Dabei ist 0 unser View.

Anschließend fragen wir ab, ob der Shader kompiliert wurde. Wenn ja, setzen wir, wie im ersten Tutorial gezeigt, den Shader, zeichnen die Oberfläche mit draw_surface(surface, x, y) und beenden den Shader mit shader_reset(). Im Prinzip ist das also relativ einfach, weshalb wir nun endlich zu den eigentlichen Shadern kommen. Hierfür habe ich ein paar vorbereitet.

Autor

Abonnieren
Benachrichtige mich bei
guest

0 Comments
Inline Feedbacks
Alle Kommentare anzeigen