Wie rendere ich meine Grafik am besten?

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

  • Wie rendere ich meine Grafik am besten?

    Hi,

    Ich bin relativ neu in Objective-C und versuche mich momentan an einem 2D TowerDefense Spiel fürs iPhone.
    Nachdem ich einige Performance Probleme hatte, habe ich versucht, meinen Code so weit es geht "auszumisten" und habe unter anderem auch eine Trennung von Spiellogik-Update und Grafik-Rendering in meiner Main-Gameloop vorgenommen. Trotzdem läuft das Spiel nicht einwandfrei, was offensichtlich daran liegt, dass sämtliche Objekte klassische UIViews (ImageView, Button, usw) sind. Sowohl die Creeps als auch Tower und Geschosse müssen von der iPhone Hardware also speicherintensiv gerendert werden.
    Meine Frage ist nun, wie ich das Rendern der Grafik einfacher bzw. schneller und eleganter lösen kann, als mit UIViews, setImage: und setCenter:
    Ich habe schon überlegt, auf OpenGL umzusteigen, was mir jedoch weder sinnvoll noch dieser relativ einfachen Aufgabe angemessen erscheint - oder?
    Was ist CoreGraphics, hat das was mit meiner Frage zu tun und ist das in dieser Situation sinnvoll? :P
    Auch von Bitmap-Texturen oder so habe ich schonmal gehört - kann mir jemand erklären, was es damit auf sich hat?

  • RE: Wie rendere ich meine Grafik am besten?

    Original von knl
    Hi,

    Ich bin relativ neu in Objective-C und versuche mich momentan an einem 2D TowerDefense Spiel fürs iPhone.
    Nachdem ich einige Performance Probleme hatte, habe ich versucht, meinen Code so weit es geht "auszumisten" und habe unter anderem auch eine Trennung von Spiellogik-Update und Grafik-Rendering in meiner Main-Gameloop vorgenommen. Trotzdem läuft das Spiel nicht einwandfrei, was offensichtlich daran liegt, dass sämtliche Objekte klassische UIViews (ImageView, Button, usw) sind. Sowohl die Creeps als auch Tower und Geschosse müssen von der iPhone Hardware also speicherintensiv gerendert werden.
    Meine Frage ist nun, wie ich das Rendern der Grafik einfacher bzw. schneller und eleganter lösen kann, als mit UIViews, setImage: und setCenter:
    Ich habe schon überlegt, auf OpenGL umzusteigen, was mir jedoch weder sinnvoll noch dieser relativ einfachen Aufgabe angemessen erscheint - oder?
    Was ist CoreGraphics, hat das was mit meiner Frage zu tun und ist das in dieser Situation sinnvoll? :P
    Auch von Bitmap-Texturen oder so habe ich schonmal gehört - kann mir jemand erklären, was es damit auf sich hat?

    Schneller als mit OpenGL ES wirst du es nicht hinkriegen. BTW. kann man ohne Code nicht viel dazu sagen, ob es Sinn macht oder nicht.

  • gibt es keine einfachere Methode, Grafiken schnell und einfach zu rendern als mit OpenGL ES?

    Ein Beispiel für meinen Code ist beispielsweise ein Geschoss, welches eine Subklasse von UIImageView ist. Im Konstruktor rufe ich [self setImage:[UIImage imageNamed:@"xy.png"]] auf und bei jedem Durchlauf der render: Methode wird [self setCenter:currentPos] aufgerufen. Wenn es ein Creep trifft folgt [self removeFromSuperview] und self=nil.
    Da ich natürlich häufig viele Tower mit einer Feuerrate von jeweils 0.5 Sekunden auf dem Feld stehen habe, sind das eine ganze Menge Objekte, die erzeugt, gerendert, bewegt und zerstört werden ... und das würde ich gerne einfache gestalten.

    Würde ich auf OpenGL ES umsteigen, müsste ich mein gesamtes Projekt neu aufziehen und OGL von Grund auf lernen - mit einem vernünftigen (auch englischen) Tutorial, welches sich auf 2D bezieht hätte ich nicht das das geringste Problem damit ...

    Da ich aber keines gefunden habe, frage ich nun nach anderen, einfacheren Methoden =)

  • Hach ja das gute alte Printmedium =) Natürlich sind Bücher toll aber immerhin kosten sie meist über 25€ ... und was gibt es alles kostenlos im Internet? Wenn kein Weg an OGL vorbei führt kauf ich mir das Buch eben, aber es geht mir eher um einfachere Lösungen - kann doch nicht sein, dass die einzige Möglichkeit, ein simples Spiel zu programmieren, OpenGL ES erfordert!

    EDIT: Noch eine Anmerkung bezüglich des Buches: 49€ sind schon ein Wort und der Fokus liegt mal wieder auf der 3D-Programmierung. Natürlich kann man das irgendwie auch auf 2D anwenden, für einen Anfänger stellt das allerdings erstmal ein Problem dar.

  • Original von knl
    gibt es keine einfachere Methode, Grafiken schnell und einfach zu rendern als mit OpenGL ES?

    Einfacher schon, schneller nicht.

    Versuch dich mal an Core Animation, je nach Anzahl deiner Views kann das einen signifikanten Performance-Vorteil bringen. Also statt Subviews Instanzen von CALayer verwenden. Um Größenordnungen wirst du dein Programm damit aber eher nicht beschleunigen können.

  • Original von knl
    Hach ja das gute alte Printmedium =) Natürlich sind Bücher toll aber immerhin kosten sie meist über 25€ ... und was gibt es alles kostenlos im Internet? Wenn kein Weg an OGL vorbei führt kauf ich mir das Buch eben, aber es geht mir eher um einfachere Lösungen - kann doch nicht sein, dass die einzige Möglichkeit, ein simples Spiel zu programmieren, OpenGL ES erfordert!

    EDIT: Noch eine Anmerkung bezüglich des Buches: 49€ sind schon ein Wort und der Fokus liegt mal wieder auf der 3D-Programmierung. Natürlich kann man das irgendwie auch auf 2D anwenden, für einen Anfänger stellt das allerdings erstmal ein Problem dar.


    49€ sind doch eher normal für Fachbücher, außerdem komme ich dann meiner Finca auf Malle ein Stück näher ;)
    Spaß beiseite, du wirst nicht drum rum kommen, dich mit OpenGL ES anzufreunden, wenn dir ein Buch zu teuer ist, dann schau dir einfach die vielen Tutorials im Netz dazu an.
    Es gibt keine bessere Möglichkeit Grafik schnell zu rendern als die besagte!

    BTW: In meinem Buch ist ein kleines Asteroids-Game dabei vollkommen in 2D, der kommt mit ner handvoll Code aus, der wie ich meine recht einfach zu verstehen ist.

  • Ich kenn ja dies UIImage nicht. Aber wie ich knl so verstehe, läd er auch andauern das "xy.png" von der "Festplatte".
    Cached UIImage von sich aus, oder läd der jedes mal das Bild neu? Weil sonst wird man bei solchem Vorgehen auch mit OpenGL nicht schneller sein, wenn die Flaschenhälse woanders liegen.
    ♥C++

  • Original von zermelo
    Ich kenn ja dies UIImage nicht. Aber wie ich knl so verstehe, läd er auch andauern das "xy.png" von der "Festplatte".

    Wo steht das?

    Cached UIImage von sich aus, oder läd der jedes mal das Bild neu? Weil sonst wird man bei solchem Vorgehen auch mit OpenGL nicht schneller sein, wenn die Flaschenhälse woanders liegen.

    Ich denke er hat es verstanden um was es geht.

  • Original von wolf_10de
    Original von zermelo
    Ich kenn ja dies UIImage nicht. Aber wie ich knl so verstehe, läd er auch andauern das "xy.png" von der "Festplatte".

    Wo steht das?


    Original von knl
    Ein Beispiel für meinen Code ist beispielsweise ein Geschoss, welches eine Subklasse von UIImageView ist. Im Konstruktor rufe ich [self setImage:[UIImage imageNamed:@"xy.png"]] auf und bei jedem Durchlauf der render: Methode wird [self setCenter:currentPos] aufgerufen. Wenn es ein Creep trifft folgt [self removeFromSuperview] und self=nil.

    Hervorhebungen von mir. Hab ich was falsch verstanden?
    ♥C++

  • Original von zermelo
    Original von wolf_10de
    Original von zermelo
    Ich kenn ja dies UIImage nicht. Aber wie ich knl so verstehe, läd er auch andauern das "xy.png" von der "Festplatte".

    Wo steht das?

    Original von knl
    Im Konstruktor rufe ich [self setImage:[UIImage imageNamed:@"xy.png"]] auf und bei jedem Durchlauf der render: Methode wird [self setCenter:currentPos] aufgerufen.

    Hervorhebungen von mir. Hab ich was falsch verstanden?

    Da steht 'Konstruktor', das beißt sich mit 'andauernd'.
    Aber sonst stimmts. Der Turm wird ja öfter als einmal schießen. ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von Lucas de Vil
    Original von zermelo
    Original von wolf_10de
    Original von zermelo
    Ich kenn ja dies UIImage nicht. Aber wie ich knl so verstehe, läd er auch andauern das "xy.png" von der "Festplatte".

    Wo steht das?

    Original von knl
    Im Konstruktor rufe ich [self setImage:[UIImage imageNamed:@"xy.png"]] auf und bei jedem Durchlauf der render: Methode wird [self setCenter:currentPos] aufgerufen.

    Hervorhebungen von mir. Hab ich was falsch verstanden?

    Da steht 'Konstruktor', das beißt sich mit 'andauernd'.
    Aber sonst stimmts. Der Turm wird ja öfter als einmal schießen. ;)

    Eben drum. Darum doch "andauernd" :P
    ♥C++

  • Original von zermelo
    Eben drum. Darum doch "andauernd" :P

    Zusammenfassend kann man sagen: Bild einmalig als UIImage laden und im Konstruktor dann einfach nur zuweisen sollte eine Performancesteigerung zur Folge haben.
    +für eigene Projekte notier+
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Original von Lucas de Vil
    Original von zermelo
    Eben drum. Darum doch "andauernd" :P

    Zusammenfassend kann man sagen: Bild einmalig als UIImage laden und im Konstruktor dann einfach nur zuweisen sollte eine Performancesteigerung zur Folge haben.
    +für eigene Projekte notier+


    Nicht nur aus Performance-Gründen sollte man ein Image aus dem Bundle per "UIImage imageNamed:..." zur Laufzeit höchstens einmal laden. Das Image wird dann nämlich auch nicht beim Releasen wieder aus dem Speicher entfernt.

    Lädt man z.B. mit dieser Methode 100x das Image aus dem Bundle, dann hat man es auch 100x im Speicher. Das man dadurch bei max. 10MB Arbeitsspeicher für eine App ganz schnell wieder im Springboard landet, sollte einem dann nicht mehr verwundern...

  • Die Herrangehensweise ist suboptimal, man baue sich ein Objekt (welches man beliebig oft erzeugen kann) und weise diesen dann immer das selbe Bild zu.

    Quellcode

    1. Image *irgendeins;
    2. .
    3. .
    4. Spielobject *c;
    5. [c setImage: irgendeins];
    6. .
    7. Spielobject *z;
    8. [z setImage: irgendeins];
    9. .
    10. .

    Und fertig ist die Suppe. Das hat auch nix mit Quartz, OpenGL, oder CG zu tun, das ist eine grundsätzliche Überlegung wie ich meine Objekte am performantesten zur Laufzeit erzeuge.
    Es geht ja nicht darum ein Bild zu erzeugen, sondern ein "Spielobjekt" welches grafisch durch ein Bild repräsentiert wird.
    Wie in einem "normalen" Programm hat auch jedes Spielobjekt (egal in welchem Spiel auch immer) bestimmte Attribute und eines davon ist "wie" es auf dem Schirm ausgegeben wird.