Suchergebnisse

Ja, da war ein kleiner Flüchtigkeitsfehler drin. Richtig wäre eigentlich: GML-Quellcode (1 Zeile)

Das geht prima ohne Surfaces. Nicht getesteter Code: GML-Quellcode (13 Zeilen) Sollte auch wunderbar schnell gehen und mit genügend Ecken auch wie ein Kreis aussehen (intern wird der GameMaker Kreise ganz ähnlich zeichnen. In Studio kann man sogar die Anzahl der Ecken einstellen, die ein Kreis haben soll... Wenn du mehr Kontrolle über die Farben haben willst (zum Beispiel ein Farb- oder Transparenzverlauf von der Mitte nach außen), kannst du statt draw_vertex auch draw_vertex_color verwenden...

Hört sich doch noch überschaubar an... In Grafikprogrammen kannst du dir recht einfach alle Pixel einer bestimmten Farbe geben lassen und die auf eine neue Ebene extrahieren. Dann Farbe raus, Helligkeit anpassen und fertig.

Falls es nur um bestimmte Bereiche des Bildes geht, die den gleichen Farbwert in verschiedener Helligkeit haben sollen (wie zum Beispiel Einheiten in einem Strategiespiel, die entsprechend ihrer Fraktion eingefärbt werden), kann man diese Bereiche auch vorher aus dem Bild ausschneiden, entfärben, aufhellen und später im Spiel zusätzlich mit angepasstem image_blend zeichnen. Bescheuertes schnell gepixeltes Beispielbild: gm-d.de/wbb/index.php/Attachme…2a9d0a0a686cdc5cf76901f77 GML-Quellcode (3 Zei…

Du kannst dir die Pixeldichte mit display_get_dpi_x() und display_get_dpi_y() ausgeben lassen. Wenn du das in deine Größen und Abstände mit einrechnest, bekommst du sozusagen pixelunabhängige Grafiken die theoretisch auf allen Geräten gleich groß erscheinen sollten. Ein Button würde auf einem kleinen Smartphone einen viel größeren Bereich des Bildschirms einnehmen als auf einem großen Tablet, die Größe für den Finger wäre aber gleich.

Den iPhone/iPod gibt es in diesen Auflösungen: 480 x 320 (5:4) 960 x 640 (5:4) 1136 x 640 (16:9) Das iPad gibt es in: 1024x768 (4:3) 2048x1536 (4:3) Android-Geräte gibt es in vielen Auflösungen, zB: 320x240 (4:3) 800x480 (5:3) 854x480 (16:9) 1024x600 (~7:4) 1280x720 (16:9) 1280x800 (16:10) ... Du kannst dir also aussuchen, an welche Auflösung du am nächsten kommen willst. Empfehlenswert ist es, die Höhe fix zu machen (zum Beispiel 640 Pixel) und die Breite abhängig vom tatsächlichen Seitenverhäl…

GM:Studio kann doch inzwischen selbst vernünftig oggs abspielen oder nicht? EDIT: Oha, streamen schreibst du. Das weiß ich natürlich wiederum nicht...aber Musik sollte im GM:Studio an sich gestreamt werden. Was genau hast du denn vor?

Kann mich leider nicht mehr erinnern, wieso genau Subversion da das Problem gewesen sein soll, aber dass git oder Mercurial Subversion nicht nur im Punkt Dateien löschen einen Schritt voraus sind, sollte schon klar sein.

Die unerfindlichen Gründe haben soweit ich weiß irgendwas mit Subversion zu tun. Das kommt anscheinend durcheinander, wenn die Dateien einfach so gelöscht werden.

GML-Quellcode (6 Zeilen)Sowas im Step Event sollte eigentlich tun. Könnte höchstens sein, dass der Radius 5 zu klein ist. Außerdem wird so nur ein Object pro Step entfernt. Wenn du alle entfernen willst, die im Radius sind, wäre eine Schleife durch alle Instanzen wahrscheinlich besser: GML-Quellcode (6 Zeilen)

Müsste das nicht so gehen: (Versteckter Text)

Idealerweise ordnest du deine Texturgruppen so, dass jede Gruppe nur eine Seite hat. In den Global Game Settings für Windows findest du irgendwo eine Preview der Texturgruppen. Weiß nicht genau, ob das bei iOS auch mit drin ist...

Keine Ahnung was die texture_preload-Funktion genau macht und ob sie eine neue aber noch undokumentierte Funktion oder eine alte und nicht mehr unterstützte Funktion ist. Der Bug dazu scheint noch offen zu sein... Eigentlich müsste es aber reichen nur jeweils eine Grafik von jeder Texture Page (Texture Groups können mehrere Pages enthalten) zu zeichnen. Dann ist die komplette Textur im Speicher. Du musst nicht jedes Sprite zeichnen. EDIT: Scheint eine alte Funktion zu sein, die unter Studio nich…

Die Texturen werden immer dann geladen, wenn ein Sprite darauf zum ersten mal gezeichnet werden. Du könntest also in einer Schleife am Anfang deines Spiels einfach mal alle Frames deiner Sprites zeichnen. Ich hab es nicht ausprobiert, aber es könnte klappen. Ich würde dir aber empfehlen, die Texturgruppen so aufzuteilen, dass du eben NICHT alle Texturgruppen gleichzeitig im Speicher haben musst!

Das ist von Gerät zu Gerät unterschiedlich soweit ich weiß...

Ist bei Studio meines Wissens nach nicht mehr so, dass alles in die exe gepackt wird. Da liegen dann mehrere Dateien im Hauptverzeichnis, bei Windows zB. noch eine data.win. Die Texture Groups enthalten mehrere Grafiken und werden erst dann in den Speicher geladen, wenn eine dieser Grafiken gezeichnet werden soll. Mit draw_texture_flush() wirfst du wieder alle Texturen aus dem Speicher (ideal zum Beispiel beim Levelwechsel). Das alles löst aber natürlich nicht das Problem des langsamen Kompilier…

Das mit den externen Ressourcen trifft auf GM 8.1 zu, bei Studio kann man das so 1:1 nicht mehr behaupten. Zumindest schreibt das Russell Kay (CTO von YoYoGames): Zitat: „BTW - loading of external resources is a bad idea in GM:S as they have a large overhead in storage and rendering, the rules on GM:S are very different from old GM so I would recommend that you do NOT load from external resources, use internal resources and Texture Groups to manage graphical resources. “

Pack einfach mal das ins Animation End Event: GML-Quellcode (3 Zeilen)

Hilft das vielleicht weiter? Skript Harte Pixel

macht es einen Unterschied, wenn du stattdessen 1/delta_time ausgeben lässt?