Mehrere Fragen zu Optimierung/Programm

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

  • Mehrere Fragen zu Optimierung/Programm

    Hallo zusammen,
    ich habe mal mehrere Fragen zum Game Maker.
    Ich hoffe ihr könnt mir da weiter helfen.
    Ich habe bin jetzt mit AS3 gearbeitet und möchte jetzt umsteigen.

    Wenn ich einen Raum wechsel, sind die Instancen noch irgendwie im Ram oder so ähnlich? Sollte ich die vorher löschen?
    Wenn ich Explosionen mach, was ist da besser? Eine Bilderfolge? Den internen Effekt? Partikel?

    Ich möchte duplicate_sprite benutzen um die Spiele besser zu optimieren.
    Ich versteh das nur nicht wirklich. Muss dazu das Sprite dazu schon auf der Bühne sein? Also im Raum?

    Gibt es eine Möglichkeit, bei Raumwechsel zb den Ram zu leeren?
    Ich hab diesen flush Befehl benutzt, aber keine Verbesserung gespürt.
  • maclor schrieb:

    Wenn ich einen Raum wechsel, sind die Instancen noch irgendwie im Ram oder so ähnlich? Sollte ich die vorher löschen?

    Die Instanzen und alle lokalen Variablen sollten automatisch vernichtet werden, esseidenn du machst die Objekte persistent.
    Auf die Weise könntest du die entsprechenden Objekte bei einem Raumwechsel mitnehmen.
    Was die Ressourcenverwaltung angeht ist der Gamemaker sicher nicht Weltklasse, aber das automatische Löschen von Instanzen sollte er können.

    maclor schrieb:

    Wenn ich Explosionen mach, was ist da besser? Eine Bilderfolge? Den internen Effekt? Partikel?

    Kommt darauf an was du eigentlich erreichen willst. Wenn du Feuerwerkskörper simulieren willst dann sind Partikel sicher keine schlechte Option,
    Wenn sich die Explosion auf einen einigermaßen kleinen Radius beschränkt und nicht jedes mal zufällig generiert werden soll, dann kommst du sicher mit einer Bilderfolge gut weg.
    Die internen Effekte ... naja gehen zur Not auch, für Testzwecke würde ich sagen, für alles andere sind sie zu gering aufgelöst, haben zu wenig Variation, o.ä. aber für Anfänger sind sie sicher nicht schlecht, zum Herumspielen.
    Am besten findet man das durch Ausprobieren heraus.

    maclor schrieb:

    Ich möchte duplicate_sprite benutzen um die Spiele besser zu optimieren.

    Du meinst wahrscheinlich sprite_duplicate() oder? Inwiefern möchtest du damit etwas optimieren? Wenn du ein Sprite duplizierst ist es doppelt im RAM vorhanden.
    Oder willst du mehrere Instanzen von einem Objekt erstellen, und hast bisher für jede Instanz ein neues Objekt erstellt?

    maclor schrieb:

    Gibt es eine Möglichkeit, bei Raumwechsel zb den Ram zu leeren?
    Ich hab diesen flush Befehl benutzt, aber keine Verbesserung gespürt.

    Wie meinst du das mit "gespürt"? Hat das Spiel geruckelt, und nachher immer noch geruckelt?
    Der flush-Befehl ist dafür da Texture-Pages aus dem Speicher zu löschen, bezieht sich also auf Sprites, Backgrounds, u.ä. Macht im Normalfall aber keinen großen Unterschied.
    Für welche Plattform entwickelst du?
  • Danke erstmal für die Antworten.
    Ich entwickel für Mobile Geräte.
    Zu den sprite_duplicate.....nein ich habe schon instancen erstellen....von einen Object.
    Ich habe auf einer Seite gelesen, das durch jede Instance auch die Textur, also das Spritesheet? nochmal komplett geladen wird und das man das eben mit sprite_duplicate verhindern kann.
    Die Optimierungstips sind sehr unterschiedlich, ich versuche einfach zu verstehen wie der Game Maker da so arbeitet.

    Zu den löschen beim Raumwechsel.
    Wie ist das bei den Partikel?
    Ich habe gesehen das, wenn ich einen Raumwechsel, die Partikel im neuen Raum noch kurz fliegen.
    Der Ermitter ist ja dann weg, und die Partikel selber? Löschen sich die dann? Ist bestimmt eine dumme Frage. Bitte um Verständniss ;)
  • maclor schrieb:

    Ich habe auf einer Seite gelesen, das durch jede Instance auch die Textur, also das Spritesheet? nochmal komplett geladen wird und das man das eben mit sprite_duplicate verhindern kann.

    Wenn du das Debug-Interface mit show_debug_overlay() einschaltest, dann kannst du sehen wieviele Texture-Swaps pro Step gemacht werden. Das ist vielleicht das was du meinst.
    Die linke Zahl (in Klammern) gibt dir dabei die Anzahl an Texture Swaps an. Je mehr Texturen vorhanden sind desto mehr Swaps müssen potenziell gemacht werden. Eine Texture Page entspricht z.B. einer Größe von 1024x1024 Pixeln.
    Du kannst das aber ganz gut beeinflussen indem du Texture Groups bildest (Global Game Settings > Texture Groups).
    Im Sprite- und Background-Menü kannst du dann die entsprechenden Sprites/Backgrounds den Groups zuweisen. Da empfiehlt es sich z.B. alle für ein Level oder eine Umgebung relevanten Texturen einer eigenen Texture Page zuzuweisen,
    dann kann man die Texture-Swap-Anzahl erheblich reduzieren.
    In den Global Game Settings kann man im Reiter des gewünschten OS's dann die Größe der Texture Page zuweisen - solte man normalerweise so lassen wie es in der Standardeinstellung ist.
    Es gibt da auch einen Preview-Button, um zu testen wie belegt die einzelnen Pages schon sind.

    Es gibt dabei keinen zusätzlichen Nachteil wenn ein Objekt oder Sprite mehr oder weniger dieselbe Textur benutzt - zumindest nicht vom Texturen-Standpunkt.
    Da ist es eher von Nachteil, wenn man das gleiche Sprite dupliziert, denn der GM weiß nicht ob es sich beim duplizierten Sprite um die gleiche Textur handelt wie beim ursprünglichen Sprite.
    Wenn man das während der Laufzeit macht muss dafür so weit ich weiß eine neue Texture Page generiert werden, nur für dieses eine Sprite -> Texture-Swap-Anzahl und V-RAM-Belegung geht unnötig in die Höhe.

    maclor schrieb:

    Zu den löschen beim Raumwechsel.
    Wie ist das bei den Partikel?
    Ich habe gesehen das, wenn ich einen Raumwechsel, die Partikel im neuen Raum noch kurz fliegen.
    Der Ermitter ist ja dann weg, und die Partikel selber? Löschen sich die dann?

    Das kommt darauf an, wie lange die Lebenszeit der Partikel ist. Sieh mal nach "part_type_life(ind, life_min, life_max)" in der Hilfe, das sollte es beantworten.

    maclor schrieb:

    Ist bestimmt eine dumme Frage. Bitte um Verständniss

    Es gibt nur dumme Antworten. ;)

    Btw. hier gibt es mehr zum Thema Texture-Swaps und Optimierung.
  • Es gibt nur dumme Antworten.

    Ich bin das vom Flash Forum gewohnt das man nur dumm angemacht wird....so ala...wie du weist das nicht?
    Find ich klasse das das hier anders ist und mit so viel Gedult gezeigt wird.
    Den show_debug hab ich schon gefunden ja, hab mich auch mal mit den Debugger probiert. Leider blick ich da auch noch nicht so ganz durch auf was ich den achten soll.
    Mit den Zahlen was du sagtest ist mir aber auch alle fälle mal geholfen. Gibt es denn vielleicht etwas wo der Debugger genau beschrieben wird?
    Die Hilfe die beim Game Maker dabei ist, geht nicht auf alles ein.
  • Ich bin das vom Flash Forum gewohnt das man nur dumm angemacht wird....so ala...wie du weist das nicht?
    Find ich klasse das das hier anders ist und mit so viel Gedult gezeigt wird.

    Wir fressen hier schon niemanden auf. XD

    Den show_debug hab ich schon gefunden ja, hab mich auch mal mit den Debugger probiert. Leider blick ich da auch noch nicht so ganz durch auf was ich den achten soll.
    Mit den Zahlen was du sagtest ist mir aber auch alle fälle mal geholfen. Gibt es denn vielleicht etwas wo der Debugger genau beschrieben wird?
    Die Hilfe die beim Game Maker dabei ist, geht nicht auf alles ein.

    Den debugger selber brauchst du eigentlich nur zu verwenden, wenn du irgendeinen Bug nachverfolgen möchtest. (und selbst da ist das kein muss. ich verwende ihn so gut wie garnicht XD)
    Ansonsten brauchst du (um die performance messen zu können) nur die "show_debug_overlay();" Funktion.
    Hier kannst du über die grafische darstellung des debug-overlays nachlesen:
    LINK

    Was ich hier noch hinzufügen kann ist dass (sofern du nicht für mobile-platformen entwickelst) dir keine sorgen bezüglich texture-swaps machen solltest.
    Diese haben zwar schon einen performance-impact, sind aber für PCs in diesem zeitalter gar kein problem. (Ausgenommen die mobile-devices. Android,IOs, usw...)
    Was deutlich schwerer ins gewicht fällt sind die draw-calls (also jegliche draw_sprite, draw_background, draw_line,etc...) aufrufe die eben etwas auf den Bildschirm zeichnen. Diese sind sehr CPU intensiv und sollten daher auf einem minimum gehalten werden. (Das ist auch der Grund nummer 1 wieso viele Spiele von unerfahreneren GM-entwicklern relativ schlechte performance aufweisen.)

    Und willkommen im Forum! :)

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

  • Willkommen im Forum :)

    Und hier auch mal ein nützlicher Link zu sachen Performance und GM:Studio: yoyogames.com/tech_blog/75

    Dort zeigt Mark Alexander einige Möglichkeiten auf, dein Spiel zu optimieren zum Thema Arrays, Variablen, Texture Swaps und Vertex Batches etc.
    Allerdings in Englisch.
  • Das die Draw Befehle sehr auf den CPU gehen hab ich gemerkt ja :)
    Ich habe zwei Buttons gezeichnet die als Steuerung auf dem Handy dienen. Das hat sich sofort bemerkbar gemacht.
    Vielen Dank für die nette Aufnahme....werde bestimmt öfters die nächste Zeit mal Fragen haben :D
    Und danke für die Links. Naja Englisch....soweit komme ich schon zurecht damit :)