2D Lighting

    • Skript

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • 2D Lighting

      Hallo zusammen,

      als hier vor einiger Zeit das Thema 2D Beleuchtung aufkam, war ich selber motiviert mal was in die Richtung zu probieren. Herausgekommen ist dabei die Demo im Anhang. Ich würde es nicht als vollständige Engine bezeichnen, da man sicher noch einiges verbessern und hinzufügen könnte. Allerdings hatte ich nicht mehr so die Lust noch länger daran zu arbeiten, aber ich wollte euch mein Ergebnis trotzdem zeigen. Denn vielleicht mag es ja der ein oder andere in irgendeiner Weise nutzen. Eine separate Dokumentation gibt es nicht, jedoch steht in jedem Script eine kurze Beschreibung. Ich denke zusammen mit dem Beispiel sollte das genügen um sich hineinzufinden.

      Die Scripts sind unter anderem in folgende Ordner unterteilt:
      • scene: Repräsentiert einen Ausschnitt des Raums, auf den Licht und Schatten gerendert werden sollen. Für gewöhnlich erstellt man eine scene in der Größe der view und lässt sie dieser folgen.
      • convex: Erstellt Objekte, die Schatten werfen, in Form von konvexen Polygonen. Alle Hindernisse im Raum müssen aus solchen Polygonen gebaut werden.
      • source: Dient dem Erstellen von Lichtquellen, welche einige Eigenschaften wie z.B. Reichweite und Lichtfarbe besitzen. Sie haben zudem einen Radius, welcher zu weichen Kanten der Schatten führt.

      Natürlich verbraucht die Engine GM-typisch relativ viele Ressourcen. Ich habe es schon so gut wie möglich optimiert, indem z.B. nur Objekte in Reichweite einer Lichtquelle gerendert werden und auch nur Lichtquellen in Reichweite der aktuellen scene betrachtet werden. Für einen ernsthaften Einsatz in einem Spiel sollte man wohl trotzdem recht sparsam mit Objekten und Lichtquellen umgehen. Aufgrund der Performance des GM sehe ich auch keinen Grund die Engine noch auszubauen.

      Um die Engine in einem Projekt zu nutzen, einfach nur den Ordner mit den Scripts exportieren/importieren. Ihr dürft sie natürlich frei verwenden, verändern oder erweitern.

      Bugs könnt ihr gerne melden. Neue Features wird es aber wie gesagt eher nicht geben.

      Nun viel Spaß damit!


      Version 1.01
      • Das automatische Rendern in jedem Step kann mittels scr_light_scene_auto an- oder ausgeschaltet werden.
      • Mit scr_light_scene_render lässt sich eine scene manuell rendern, was besonders nützlich ist, wenn automatisches Rendern ausgeschaltet ist.

      Download
      Bilder

      • light.jpg

        218,67 kB, 800×600, 777 mal angesehen

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Bl@ckSp@rk () aus folgendem Grund: Version 1.01

    • Na das klingt doch mal sehr gut.
      Habs mal getestet und die Demo lief auf 60fps. Allerdings ist das nicht verwunderlich auf einem 6-Kern Prozessor.
      Ich muss es mal auf einem "Steinzeitrechner" testen. Wenn's dort einigermaßen flüßig läuft, dann werde ich es deine Engine
      in meinem Projekt nutzen.
      Auf jeden Fall Props an dich Bl@ckSp@rk ;)

      MfG

      Albert Einstein schrieb:

      Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind.

    • florpp schrieb:

      C5_Booster schrieb:

      Allerdings ist das nicht verwunderlich auf einem 6-Kern Prozessor.
      Soweit ich weiß untersützt der GM nur 1nen Kern, 6 Kerne sind also absolut nutzlos :P

      Falsch. Windows verteilt die Auslastung von haus aus zu einem gewissen teil auf alle verfügbaren kerne [/klugscheiß] ;)
      Trotzdem ist die Rechenleistung von programmierten Multi-Core Programmen deutlich höher, als durch Windows verteilte Single-Core Application.

      Eigentlich schade, dass der GM immer noch auf einen Kern programmiert ist - wo doch fast jeder heutzutage min. 2 hat.

    • Wobei man sagen muss dass Multithreading (Sprich: nutzung mehrerer Threads die man auch auf 2 Kerne verteilen kann) etwas schwieriger ist als die ganze Single-Core sache.
      Bei Multithreading auf 2 Kernen hast du wirkliches Pararrelles arbeiten von 2 Prozessen die unabhängig voneinander sind. Stell dir vor du bearbeitest eine einzige Variable mit den 2 Prozessen.
      Durch die unbestimmte Reihenfolge könnte es dazu komme ndas Werte einfach so hin und herspringen und am ende nicht mit dem endergebniss übereinstimmen. (= Inkonsistenz)
      (Also Prozes 1 Liest die Variable und adiert einen Wert.. Prozess 2 Liest die Variable auch und subtrahiert einen Wert. Am ende Speichern beide Prozesse die Variable wieder im Ram. Der Wert desjenigen Prozesses bleibt erhalten, der zuletzt gespeichert hat.)
      Man müsste da so programmieren, dass ein Prozess eine Variable während das Arbeitens für andere Prozesse unzugänglich macht. Die anderen Prozesse warten sozusagen auf ihren "Auftritt".
      (Leicht mit dem Klogang vergleichbar. Das Klo ist die Variable und der "User" der Prozess. XD Nur 1 Prozess kan die Variable zur selben Zeit bearbeiten. Die anderen Prozesse warten. Während dessen dient die "Tür" mit ihren offen/besetzt Schild als Markierung ob die variable gerade frei ist oder benutzt wird.)

      Multi-threading bringt natürlich einen hohen PerformanceSchub. Man muss jedoch ein wenig Erfahrung haben und sehr Vorsichtig beim einsatz sein. (Vorsichtig in Form von "Ja keine Bugs verursachen".)

      bzw. Echt nette Engine. Erinnertmich ein wenig an die 2D Licht engine die ein Franzose (oder war das ein Spanier?) gemacht hat. Hatte ähnliche Effekte. :D

    • Danke erstmal für Lob und Kommentare! :) (Auch wenn die meisten davon bis jetzt Offtopic waren)

      bzw. Echt nette Engine. Erinnertmich ein wenig an die 2D Licht engine die ein Franzose (oder war das ein Spanier?) gemacht hat. Hatte ähnliche Effekte. :D

      Auf YouTube findet man so einige Demos für 2D Beleuchtung. Die meisten sind natürlich nicht im GM erstellt, aber man kann sich inspirieren lassen. ;)

      Das Thema Multithreading gehört zwar nicht hier her, aber

      Falsch. Windows verteilt die Auslastung von haus aus zu einem gewissen teil auf alle verfügbaren kerne [/klugscheiß] ;)

      bringt GM Anwendungen trotzdem nichts, da Prozesse bzw. Threads nur im Ganzen einem Kern zugewiesen werden. Da GM Spiele für gewöhnlich nur aus einem Thread bestehen, nützen einem also mehrere Kerne tatsächlich nichts.

      Eigentlich schade, dass der GM immer noch auf einen Kern programmiert ist - wo doch fast jeder heutzutage min. 2 hat.

      LEWA hat das Problem schon angesprochen. Man kann nicht einfach jedes beliebige Programm automatisiert auf mehreren Kernen laufen lassen. Dieses Parallelisieren von Programmen muss man schon selber machen, indem man mehrere Threads organisiert. Dies ist oft keine leichte Aufgabe und ganz sicher ungeeignet für Programmieranfänger, für die der GM ja gedacht ist.

      Aber bitte wieder zurück zum Thema...

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Bl@ckSp@rk ()

    • Gerendert wird im Script scr_light_scene_event_step_end. Dieses wird in scr_light_global_init ins End-Step-Event der scene gesetzt, wodurch in jedem Step neu gerendert wird. Du könntest nun z.B. nach dem Erstellen der scene einfach einen step warten und dann das scene Objekt mit instance_deactivate_object deaktivieren. Vorher musst du dir natürlich mit scr_light_scene_get_surface noch die surface holen, welche du dann einfach jeden step zeichnest. Bitte beachte, dass es problematisch sein kann, einfach das End-Step-Event zu löschen und das Script manuell einmal aufzurufen, da ich das Collisionsevent nutze um alle in der Nähe befindlichen Objekte zu finden. Wenn du es so machen wolltest, müsstest du das Script scr_light_scene_event_step_end entsprechend ändern, sodass er einfach alle Lichtquellen und Polygone betrachtet statt nur die in der Nähe.

      EDIT:
      Ich habe mich spontan entschlossen das von Tice gewünschte Feature mit einzubauen. Ihr könnt euch die neue Version im ersten Post herunterladen. Man kann nun per Script das automatische Rendern an- und ausschalten und auch manuell rendern.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Bl@ckSp@rk ()

    • Gibt es die Möglichkeit dass einmal der ganze Room gerendert wird und dann gestoppt wird?/Polygone gelöscht etc. Das müsste doch das Performance Problem lösen, oder irre ich mich? Ich hab mir die Engine noch nicht heruntergeladen btw... das ist jetzt nur Kopfkino...

      out now: KNOSSOS auf itch.io
      ancient-pixel.com <<< ich freue mich über einen Besuch! ^^

    • Natürlich wäre das von der Performance her am besten. Das kann man aber nur machen, wenn sich Objekte und Lichtquellen nicht bewegen. Zudem würde man wohl ein Problem mit dem Videospeicher bekommen wenn man den ganzen Raum mit Surfaces abdecken will. Aber wenn einem das nichts ausmacht, kann man das durchaus mit der Engine umsetzen.