Compilen beschleunigen

  • Allgemein

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

  • Compilen beschleunigen

    Hallo Leute,

    Wenn ich mein Spiel auf einem ios Gerät mittels dem yoyorunner testen möchte dauert das compilen immer so ca. 4-5 Minuten. Und da ich mein Spiel noch um einiges erweitern möchte was Sprites und Levelanzahl angeht wird die Dauer wohl in Zukunft noch steigen. Das hat ein sehr uneffizientes Arbeiten zu Folge wenn ich bei jeder kleinen Änderung so lange warten muss...

    Die Ursache dafür ist wahrscheinlich dass mein Rechner zu lahm ist. Ich arbeite auf einem Mac mit Parallels Desktop damit Windows läuft, und windows hat dann nur 1GB Ram zur Verfügung und der CPU ist auch nicht der schnellste, da der Mac schon ein paar Jahre auf dem Buckel hat.

    Meine Frage lautet daher, ob ein schnellerer Rechner auch schneller compilen würde? Oder gibt es andere Möglichkeiten den Vorgang zu beschleunigen? Oder ändert sich da nichts, muss ich mit der langen Wartezeit leben? Wie lange dauert das denn bei euch so durchschnittlich und was für Rechner habt ihr?

    Würd mich über ein paar Anregungen freuen!

    Gruß,
    Pascal

  • Mit Befehlen wie sound_add(fname, kind, preload) oder sound_replace(index, fname, kind, preload) kannst du Sounds zur Laufzeit (also nachdem dein Spiel gestartet wurde) importieren/ ersetzen. Solche Befehle gibt es auch für alle anderen Ressourcen die man im GM so nutzt.
    Ich empfehle dir so viele Ressourcen wie nur möglich extern zu lagern.

    Deine "kompilierte" .exe sollte nicht größer als 20MB sein (und selbst das ist schon recht riesig). Denn es dauert nicht nur lange das Ganze zu Kompilieren sondern es dauert ebenso ewig das Spiel später zu starten. Daher ist es besser nur die Ressourcen zu laden die man auch wirklich gerade braucht. Das entlastet auch den Arbeitsspeicher.

  • 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):
    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.
    Einige meiner Spiele:

  • interceptor schrieb:

    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):
    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.


    Heisst dass dan aber nicht dass Grafiken (z.B: beim Windows export) in die exe geschrieben werden? (Bei Studio kann man auch Sounds extern laden, Musik hingegen muss intern abgespeichert werden.)
    Verursacht dies nicht das altbekannte "laden-Problem" wo die exe eine halbe ewigkeit zum initialisieren braucht und zusätzlich noch so extrem riesig wird? (Man müsste sich das mal bei Mobile devices vorstellen die nur einen Bruchteil der Rechenleistung von Mdoernen Heimcomputern haben... Zwar nutzen Smartphone Spiele keine hochauflösenden Grafiken, aber bei Musik die in die Projektdatei direkt importiert werden muss... und wenn es dann auch noch mehrere Ressourcen dieser art sind...)
    Wie soll man da dann damit arbeiten wenn man ein etwas größeres Projekt angeht? (Die compile Zeiten werden ja laut Threadersteller auch noch länger...)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von LEWA ()

  • 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 Kompilierens. Da hatte ich bisher aber auch noch keine großen Probleme. Das einzig sinnvolle scheint mir zu sein, 1. nicht jedesmal aufs Gerät zu bauen sondern öfter auch einfach im Windows/Mac zu testen. 2. Soundeffekte im Projektfile zu Testzwecken durch leere Soundfiles (bzw. sehr kurze, die kaum Speicher brauchen) zu ersetzen. Das lässt sich sicher auch leicht über eine Batch-Datei lösen, die die richtigen mit den Dummy-Sounds austauscht, je nachdem was man haben will.
    Einige meiner Spiele: