Yoyo compiler & Draw Event

  • iOS

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

  • Yoyo compiler & Draw Event

    Derzeit sitze ich an einem kleinen Projekt in GM Studio (Match3 für iOS) das an sich schon sehr gut funktioniert. Nur hatte ich leider Geschwindigkeitseinbrüche auf meinem iPad. Nach langen suchen warum das so ist, fand ich heraus das mein Spiel die performance deshalb verliert, weil ca 130 Objekte im draw gleichzeitig gezeichnet werden mit

    Quellcode

    1. draw_sprite(x,y,spr_test)

    Entferne ich den draw_sprite code im draw event, läuft es schon deutlich schneller (logisch).
    Meine Frage ist jetzt, würde das ganze schneller mit dem YYC laufen? Mein Spiel hat an sich nicht viel Code, kann da also wenig bis gar nicht optimieren. Gibt der YYC einen FPS-Boost auch bei Draw-Events oder ist da kein Unterschied? Hat überhaupt jemand den Compiler gekauft ? :rolleyes:

  • Der YoYoCompiler bringt da schon was, allgemein kann man es aber nicht sagen. Check doch mal das hier, ob du noch irgendwas optimieren kannst: yoyogames.com/tech_blog/30
    Einige meiner Spiele:

  • Der YYC hat nur einen Vorteil auf GML selbst, die Beschränkung liegt bei draw_sprite selbst und zwar bei DirectX bzw. die API die iOS nutzt (OpenGl?). Problem ist das CPU und GPU zwei getrennte Dinge sind und die meiste Arbeit vom Treiber übernohmen wird (Datenaustausch z.B.) und dazu fällt auch das Umwandeln der Drawcalls in die jeweilige Sprache die die GPU am besten verstehen kann (kenen mich Indepth nicht so gut aus, aber hoffe das passt so). Wir haben also hier verschiedene Flaschenhälse, einmal auf der CPU Seite (was dafür sorgt das die GPU zum größten Teil idelt und nichts tut) oder das die GPU zuviel tut (Texture, Shader) und die CPU idelt, dass liegt inbesondere daran das CPU und GPU async laufen, also gleichzeitig. Nun, da die Grafikkarten für 3D-Polygone ausgelegt sind und nicht für 2D-Sprites, werden diese Sprites durch 2 Dreiecke simuliert. Irgendwann ruft der GameMaker also DrawIndexedPrimitive (bei Directx, oder eine andere Draw-Funktion) auf und das ist damit ein Drawcall.

    Da das umsetzen und senden des Drawcalls an die GPU Zeit brauch (auf der CPU) kann es hier zu einem Flaschenhals kommen, je nach CPU-Performance (Takt, Cores, etc) ist es also möglich nur maximal x Drawcalls pro Frame zu haben. Hier eine Präsentation darüber von Nvidia, mit einpaar Zahlen wieviel Drawcalls so etwa möglich sind.

    Der GameMaker bietet leider keinen direkten Zugriff auf die unterliegende API (also DirectX) und damit ist es kaum möglich da weiter zu optimieren (GM:Studio scheint ja wenigstens Vertex Buffer/VBOs zu können), d.h. Batching ist hier kaum möglich. Batching ist versuchen so viele Elemente in einem Drawcall zu kriegen (dann gibt es noch so Dinge wie Hardware Instancing, bei dem versucht werden so viele Instancen von einem Model in einem Drawcall zu zeichnen).

    Ansätze:
    • (macht der GM das schon?) du kannst versuchen unnötige Sprites nicht zu zeichnen (z.B. die, die nicht im View liegen)
    • viele statische Sprites auf eine Surface zeichnen oder
    • mit den 3D-Funktionen versuchen die Sprites in ein Model (statisch) zu packen und dann alles in einem Drawcall zu zeichnen


    TL;DR: Hat weniger mit dem YYC zutun, sondern mehr darin was alles hinter dem GameMaker liegt (von DirectX/OpenGL zu GPU).

    Meine Erfahrung stammt zum größten Teil aus XNA/DirectX9, mit OpenGL oder iOS kenne mich nicht aus, aber ich gehe davon aus das das inetwa genau so ist wie auf dem PC. Vielleicht antwortet jemand der sich mit iOS und GameMaker:Studio besser auskennt als ich.

    #edit:
    Möglicherweiße kannst du auch versuchen mit einem Profiler an die ganze Sache zu gehen und schauen wo die meiste Zeit verbraten wird, wird aber wohl schwieriger beim GameMaker, weil der afair keine native Möglichkeit hat das Spiel zu profilen. Vielleicht kannst du es auch mit einem iOS-Profiler versuchen.
    wupto.net/ Nicht meine Seite!
    We love Koalas.

    GM-D-Spam-o-Meter: 32%

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von henrik1235 ()

  • Danke ! Ich habe schon ein paar Dinge ausprobiert und ich denke langsam wirds :)
    Eine Frage hätte ich aber noch (leider finde ich in Google keine konkrete Antwort..).. ist es besser wenn das Spiel (kein scrolling) auf 60 fps läuft oder eher auf 30 fps ? Ich meine, werden die iOS Spiele Grundsätzlich bzw. überwiegend auf 30 fps entwickelt oder eher auf 60 fps ?

  • Die meisten Spiele werden mit Delta timing realisiert. Heißt also es läuft immer mit maximal Geschwindigkeit und lässt alles soviel voranschreiten wie es zur relation der Dauer eines Schleifendurchlaufs(Step) benötig. Ist aber im Game Maker nicht so leicht umsetzbar, weil jeder Step eine konstante Dauer hat. Wenn das Spiel alle seine Aufgaben für einen Step erledigt hat, wartet er bis er wieder den nächsten Step ausführen darf. Wenn jetzt die Aufgaben bis zum Step-Ende nicht erledigt sind, verzögert sich der nächste Step bis diese endlich fertig sind. Ergo das Spiel verlangsamt und ruckelt. Man bekommt dadurch folgende Möglichkeiten:
    1. Man setzt den Roomspeed auf maximal 9999 und lässt die Objekte multiplitziert mit der Variable delta_time bewegen. So bekommt man immer die maximal FPS
    2. Man setzt den Roomspeed auf 60, wenn es ein kleines Spiel ist und wenig Skript ausgeführt werden muss.
    3. Man setzt den Roomspeed auf 30, wenn es ein etwas umfangreicheres Spiel ist und viel Skript ausgeführt werden muss. Hier bekommt man eh kaum mit, dass es mit 30 FPS läuft. Viel schlimmer ist es, wenn das Spiel ruckelt.