Suchergebnisse

Du brauchst ein lightsurface auf welches du dann deine Lichtquellen per blendmode und zuletzt alle Wände etc als mask draufmalst. Also Hintergrund schwarz, mit den Lichtern ausradieren, und dann wieder Schwarz verdecken wo solide Objekte sind

Eine DLL ist viel schneller, dann kannst du das ganze bei 60ticks laufen lassen,denn wenn ich nicht ganz falsch liege kommen die informationen dann eh asynchron rein. Du bräuchtest halt nur eine DLL welche beim Farbwechsel angesprochen wird, dann die Zeit misst bis ein mausclick reinkommt. Das dürfte nicht allzu umfangreich sein.

hier mal pseudocode GML-Quellcode (14 Zeilen)

Die Einheiten könnten beim Selektieren einer Ordnung unterliegen, sagen wir Einheit (E) 1 bekommt px = 0; py = 0; zugewiesen, E2 dann px = 1; py = 0; E3 px = -1; py = 0; E4 px = 0; py = 1; E5 px = 0; py = -1; E6 px = 1; py = 1; E7 px = -1; py = 1; usw. Dann musst du diese Werte nurnoch mit einem Offset multiplizieren. Ich arbeite eigentlich nie mit den Paths, das sollte aber klappen.

du könntest jeder Einheit einen Rang zuweisen(Vorzugsweise 2dimensional) und diesen als Koordinaten für einen Table mp_grid (ds_grid?) benutzen, um offsets für x und y auszulesen. Das wäre der simpelste Weg um eine Gruppierung zu erstellen, du müsstest halt nur das grid vorher genügend groß erstellen (10x10 reicht für 100 Einheiten), damit nur ausgelesen werden muss. Diese Koordinaten addierst du dann auf die Zielkoordinaten der Paths. Etwas Komplizierter aber meines Erachtens besser wäre wenn d…

du musst nur keyboard_check() benutzen

Also mit dem GM kann man sicher auch Anwendungen erstellen, Schwerpunktmäßig ist er allerdings nicht für sowas ausgelegt, du bräuchtest denke ich zumindest eine dll, am besten wäre aber das ganze direkt in C++ zu schreiben

ich würde mit current_time arbeiten

So wie ich verstanden habe hat er im Player garkein Drawevent. draw_self() ist schon richtig, hätte er halt nur ins predraw packen müssen. Hast schon Recht part_system_depth ist die richtige Funktion dann braucht man sonst nichts ändern

Wenn die Partikel im Draw ausgeführt werden dann sollte der Spieler halt in dem Fall vorher gemalt werden, also ja es reicht wenn player im predraw und partikel im draw oder später gezeichnet werden

Dann mal ihn halt im PreDraw

Bin eben erst nach Hause gekommen. Ich denke du solltest das Sprite auf ein Surface malen, den nähsten Baum finden, und wenn er damit kollidiert den Baum als Maske benutzen. GMs blend modes reichen aus um dann genau den Teil Grün erscheinen zu lassen.

Ich würde einen ganz anderen Ansatz ohne Shader bevorzugen, indem du einen Blendmode benutzt.

Ich hätte auch mal reingeguckt, allerdings hat der TS ein Passwort.

Soweit ich weiß liest die Funktion direkt aus der Texturepage

docs.yoyogames.com/source/dadi…/draw_sprite_general.html Wie soll das denn auch mit Origin Funktionieren?

Warum bitte nicht 4 Spritesheets a 4 images, eins für jede Farbe. mit sprite_index kannst du diese addressieren. Es würde allerdings schon reichen die images neu zu sortieren (0-3 blau, 4-7,rot usw...), dann kannst du die Abfrage so gestalten GML-Quellcode (1 Zeile)

GML-Quellcode (6 Zeilen)

Sorry wenn es dumm kommt, aber hast du schon physics_apply_force(xpos, ypos, xforce, yforce) ausprobiert? Man könnte doch den nächsten Partikel mit instance_nearest(part) finden und dann den Code in diesem ausführen.

Hätte eventuell doch einen Ansatz mit instance_nearest, dazu werden unpassende Instanzen vorrübergehend deaktiviert. Im Moment ist das ganze noch sehr Flexibel aber wenn nur direkt unter dem Objekt getestet werden soll kann es noch stark vereinfacht werden. GML-Quellcode (18 Zeilen) noch ungetestet sollte aber klappen.