OpenGL auf dem Iphone 4 (iOS4)

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

  • OpenGL auf dem Iphone 4 (iOS4)

    Hallo,

    ich hoffe ihr könnt mir hier in diesem Forum weiterhelfen.

    Ich beschäftige mich schon seit einiger Zeit mit der Programmierung von Software fürs Iphone 4. Ich habe mich schon durch etliche Tutorials gewühlt dennoch habe ich nicht immer das in dem Umfang gefunden was ich wollte. Die meisten Bücher beschäftigen sich mit Anwendungen fürs Iphone. Die Rede ist meist nur von View-Based Anwendungen welche man im Interface Builder zusammenschustert und in Xcode mit Code verbindet. Ich würde aber gerne eigene Spiele mit OpenGL programmieren. Bis jetzt hab ich nur etwas Erfahrung mit OpenGL in Verbindung mit Windows Plattformen.

    Ich habe folgende Fragen an euch

    Ich würde gerne, nur um mich ein wenig mit OpenGL auf dem Iphone auseinanderzusetzen zB einen Würfel in Echtzeit rendern lassen wollen. Dazu brauche ich eine möglichst aktuelle mobile Version von OpenGL.


    Wo bekomme ich diese her und was benötige ich noch für Software? Kann ich das ganze auch weiterhin in Xcode programmieren?


    lg phyte
  • Ich denke auch, dass OpenGL ES ausreichend ist.

    Alles Andere geht wunderbar in Xcode.
    Auf wr-media.net/ findest du Tutorials und sogar ein Buch über die Entwicklung von OpenGL Anwendungen mit Objective-C auf dem Mac.
    Das Buch ist nicht für das iPhone gedacht, gibt dir aber grundlegende Informationen, welche Möglichkeiten du zur Umsetzung in Xcode hast.

    Den OpenGL ES spezifischen Kram müsstest du dir dann aus der Dokumentation erarbeiten.
    «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
  • neophyte2010 schrieb:

    interessant interessant cool cool :)

    danke erstmal für die Antworten werd ich mir gleich mal ein wenig mit beschäftigen und schlau machen.

    Hab auch immer was von OpenGL ES gelesen aber bin nie drauss schlau geworden. Scheint nur eine abgespeckte Version für eingebettete Systeme zu sein wie es scheint oder lieg ich da falsch?

    Ja, ziemlich richtig. "Abgespeckt" ist aber relativ. Sind einige Dinge rausgeflogen, die man eh nicht braucht bzw. die bei >= OpenGL 3.x ohnehin nicht mehr empfohlen bzw. deprecated sind.
    C++
  • Bist du der Autor des Buches?

    Also hab bis jetzt noch nichts zu meckern :) Ist auch studienbegleitend ein informatives Buch wie ich finde.

    Hab nur eine kleine Frage am Rande, da ich gerade im Buch bei der Erklärung einiger Buffer bin. Gibt es eine Möglichkeit einen Triple Buffer zu verwenden? Im Interface Builder kann man nur zwischen Doppel- und Stereobuffer wählen. Kann auch sein das ich etwas falsch verstanden habe aber die Dreifachpufferung im Zusammenspiel mit VSync wäre doch eigentlich zu bevorzugen da keine Artefakte auftreten, nur der Speicherverbrauch ist etwas größer
  • neophyte2010 schrieb:

    Bist du der Autor des Buches?

    Also hab bis jetzt noch nichts zu meckern :) Ist auch studienbegleitend ein informatives Buch wie ich finde.

    Hab nur eine kleine Frage am Rande, da ich gerade im Buch bei der Erklärung einiger Buffer bin. Gibt es eine Möglichkeit einen Triple Buffer zu verwenden? Im Interface Builder kann man nur zwischen Doppel- und Stereobuffer wählen. Kann auch sein das ich etwas falsch verstanden habe aber die Dreifachpufferung im Zusammenspiel mit VSync wäre doch eigentlich zu bevorzugen da keine Artefakte auftreten, nur der Speicherverbrauch ist etwas größer

    Was soll ein Triple-Buffer bringen?
    Single-Buffer: Render alles gleich auf den Bildschirm. Tearing etc., kein VSync
    Double-Buffer: Render nach GL_BACK, wenn alles fertig ist (bzw. auf VSync) swap nach GL_FRONT. Keine Artefakte.
    Stereobuffer ist das gleiche zwei mal, also zwei Double-Buffer. Gerne auch Quad-Buffer genannt. Darum(?) gibt auch die NVIDIA Quadros ;)
    C++
  • Was soll ein Triple-Buffer bringen?
    Single-Buffer: Render alles gleich auf den Bildschirm. Tearing etc., kein VSync
    Double-Buffer: Render nach GL_BACK, wenn alles fertig ist (bzw. auf VSync) swap nach GL_FRONT. Keine Artefakte.
    Stereobuffer ist das gleiche zwei mal, also zwei Double-Buffer. Gerne auch Quad-Buffer genannt. Darum(?) gibt auch die NVIDIA Quadros
    Beim Zweifachbuffer können auch Artefakte auftreten wenn im Backbuffer das Bild noch nicht fertig berechnet ist und es in den Frontbuffer geschoben wird. Ist die Vertikale Synchronisation aktiviert führt das zu einem Performanceverlust da ja auf das nächste Bild gewartet wird oder liege ich falsch? Gibt es einen dritten Puffer kann schon das zweite Bild berechnet (im zweiten Backbuffer) werden und meinetwegen in den ersten Backbuffer geschoben werden sobald der erste Backbuffer zum Frontbuffer wird. Die Bildqualität ist höher und der Speicherverbrauch geringfügig erhöht. Es gibt kein Performanceverlust da Berechnung und Ausgabe fließend ineinander übergehen.


    Von StereoBuffering habe ich erst im Buch erfahren. Es wird wohl im Zusammenhang mit 3D Bildschirmen benutzt


    schlagt mich wenn ich falsch liege ;)

    Edit:

    hab grad den wiki Eintrag entdeckt:

    de.wikipedia.org/wiki/Dreifachpufferung

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

  • neophyte2010 schrieb:

    Was soll ein Triple-Buffer bringen?
    Single-Buffer: Render alles gleich auf den Bildschirm. Tearing etc., kein VSync
    Double-Buffer: Render nach GL_BACK, wenn alles fertig ist (bzw. auf VSync) swap nach GL_FRONT. Keine Artefakte.
    Stereobuffer ist das gleiche zwei mal, also zwei Double-Buffer. Gerne auch Quad-Buffer genannt. Darum(?) gibt auch die NVIDIA Quadros
    Beim Zweifachbuffer können auch Artefakte auftreten wenn im Backbuffer das Bild noch nicht fertig berechnet ist und es in den Frontbuffer geschoben wird. Ist die Vertikale Synchronisation aktiviert führt das zu einem Performanceverlust da ja auf das nächste Bild gewartet wird oder liege ich falsch? Gibt es einen dritten Puffer kann schon das zweite Bild berechnet (im zweiten Backbuffer) werden und meinetwegen in den ersten Backbuffer geschoben werden sobald der erste Backbuffer zum Frontbuffer wird. Die Bildqualität ist höher und der Speicherverbrauch und der Performanceverlust geringfügig erhöht.


    Von StereoBuffering habe ich erst im Buch erfahren. Es wird wohl im Zusammenhang mit 3D Bildschirmen benutzt


    schlagt mich wenn ich falsch liege ;)

    - Wenn das Bild nicht fertig ist, kommt es nicht in den Front-Buffer. Wenn Du es trotzdem machst, bist Du selbst schuld - mir fällt jetzt aber auf Anhieb nicht ein, wie man den Swap erzwingen könnte.
    Also kurz: Der Swap kommt immer erst, wenn das Bild fertig ist. Wenn Du den Swap aufrufst, geschieht der erst, sobald er soweit ist. Keine Artefakte

    - Triple-Buffer sind mir so noch nicht unterkommen, meinetwegen macht das der Treiber auf Wunsch. Hier soll, soweit ich das sehe, nur die Wartezeit auf den VSync und den tatsächlichen Swap überbrückt werden, in dem schon das nächste Frame angefangen wird. Programmatisch ist da wohl eher nichts zu machen.

    - Stereobuffer, ja, 3D Bildschirme (selten). Viel verbreiteter sind Shutter-Brillen mit "normalen" 120Hz Bildschirmen oder Projektoren, oder Polarisierte Brillen mit Projektoren + Filter + Polarisationserhaltenden Leinwänden ;)
    C++
  • - Wenn das Bild nicht fertig ist, kommt es nicht in den Front-Buffer. Wenn Du es trotzdem machst, bist Du selbst schuld - mir fällt jetzt aber auf Anhieb nicht ein, wie man den Swap erzwingen könnte.
    Also kurz: Der Swap kommt immer erst, wenn das Bild fertig ist. Wenn Du den Swap aufrufst, geschieht der erst, sobald er soweit ist.


    Das ist nicht ganz korrekt. Der Swap kommt bei aktivierter VSync sobald das Bild berechnet wurde. Bei deaktivierter VSync sobald es benötigt wird.


    Keine Artefakte

    Aber

    Wenn ich VSync einschalte, also warte bis das Bild im Backbuffer fertig berechnet ist, und die Berechnung selbst zu lange dauert kommt es zum Einbruch der mittleren Framerate.

    Wenn ich zb. Pro Sekunde 1 neues Bild ausgeben will aber z.B. eines der Bilder 3 Sekunden Renderzeit benötigt hat man hier ein Problem. Der Backbuffer schläft wenn das nächste Bild berechnet wurde bis die Sekunde vorbei ist. Bei dem Bild was drei Sekunden Renderzeit benötigt würde ich dann nicht mehr jede Sekunde ein neues Bild anzeigen können.


    Bei der Dreifachpufferung gibt es 3 Puffer. Einer zeigt das aktuelle Bild an. Die anderen zwei berechnen das nächste und übernächste Bild. Es gibt keinen Performanceverlust da es hier nicht zum "Flaschenhalseffekt" kommt. Die GPU wird voll ausgereizt und steht nicht zwischendurch im idle. Die Grafikkarte berechnet nämlich schon das "übernächste" Bild wenn das "nächste" Bild auch berechnet wurde. Ich kann also in der ersten Sekunde nicht nur das 2te Bild berechnen lassen sondern schon einen Teil vom dritten Bild.


    Ich frag nur weil man das nicht auswählen kann.
  • zerm schrieb:

    - Wenn das Bild nicht fertig ist, kommt es nicht in den Front-Buffer. Wenn Du es trotzdem machst, bist Du selbst schuld - mir fällt jetzt aber auf Anhieb nicht ein, wie man den Swap erzwingen könnte.
    Also kurz: Der Swap kommt immer erst, wenn das Bild fertig ist. Wenn Du den Swap aufrufst, geschieht der erst, sobald er soweit ist. Keine Artefakte


    Zerm du leidest unter Vergesslichkeit ;)
    Schau dir mal unsere "Unterhaltung" hier osxentwicklerforum.de/index.php?page=Thread&threadID=9669 an.
    Am Ende war ja geklärt was glFlush() macht.

    Am besten nochmal lesen was der Unterschied zwischen glFlush() und glFinish() ist.
  • wolf_10de schrieb:

    zerm schrieb:

    - Wenn das Bild nicht fertig ist, kommt es nicht in den Front-Buffer. Wenn Du es trotzdem machst, bist Du selbst schuld - mir fällt jetzt aber auf Anhieb nicht ein, wie man den Swap erzwingen könnte.
    Also kurz: Der Swap kommt immer erst, wenn das Bild fertig ist. Wenn Du den Swap aufrufst, geschieht der erst, sobald er soweit ist. Keine Artefakte


    Zerm du leidest unter Vergesslichkeit ;)
    Schau dir mal unsere "Unterhaltung" hier osxentwicklerforum.de/index.php?page=Thread&threadID=9669 an.
    Am Ende war ja geklärt was glFlush() macht.

    Am besten nochmal lesen was der Unterschied zwischen glFlush() und glFinish() ist.

    Hurr Durr ja, das war aber Single-Buffering. glutSwapBuffers (oder welcher Swap-Buffer Befehl auch immer) sollte implizit stehts ein glFinish() machen. Oder was willst Du mir sagen?
    C++
  • neophyte2010 schrieb:

    - Wenn das Bild nicht fertig ist, kommt es nicht in den Front-Buffer. Wenn Du es trotzdem machst, bist Du selbst schuld - mir fällt jetzt aber auf Anhieb nicht ein, wie man den Swap erzwingen könnte.
    Also kurz: Der Swap kommt immer erst, wenn das Bild fertig ist. Wenn Du den Swap aufrufst, geschieht der erst, sobald er soweit ist.


    Das ist nicht ganz korrekt. Der Swap kommt bei aktivierter VSync sobald das Bild berechnet wurde. Bei deaktivierter VSync sobald es benötigt wird.


    Keine Artefakte

    Aber

    Wenn ich VSync einschalte, also warte bis das Bild im Backbuffer fertig berechnet ist, und die Berechnung selbst zu lange dauert kommt es zum Einbruch der mittleren Framerate.

    Wenn ich zb. Pro Sekunde 1 neues Bild ausgeben will aber z.B. eines der Bilder 3 Sekunden Renderzeit benötigt hat man hier ein Problem. Der Backbuffer schläft wenn das nächste Bild berechnet wurde bis die Sekunde vorbei ist. Bei dem Bild was drei Sekunden Renderzeit benötigt würde ich dann nicht mehr jede Sekunde ein neues Bild anzeigen können.


    Bei der Dreifachpufferung gibt es 3 Puffer. Einer zeigt das aktuelle Bild an. Die anderen zwei berechnen das nächste und übernächste Bild. Es gibt keinen Performanceverlust da es hier nicht zum "Flaschenhalseffekt" kommt. Die GPU wird voll ausgereizt und steht nicht zwischendurch im idle. Die Grafikkarte berechnet nämlich schon das "übernächste" Bild wenn das "nächste" Bild auch berechnet wurde. Ich kann also in der ersten Sekunde nicht nur das 2te Bild berechnen lassen sondern schon einen Teil vom dritten Bild.


    Ich frag nur weil man das nicht auswählen kann.

    Ich kann Dir nicht folgen.
    Wenn ich den Swap freigegeben habe, wartet der bei VSync darauf, dass der Elektrodenstrahl (haha) wieder ganz oben links ist. Darum kanns da mal etwas dauern.

    Wenn ich pro Sekunde 1 Bild ausgeben will, ein Bild aber 3 Sekunden dauert, kann ich das ja nie schaffen. Egal was ich mache und was ich habe. Das letzte Bild bleibt ja aber im Frontbuffer, bis das neue fertig ist.
    Wenn das eine Bild 3 Sekunden dauert, kann die GPU ohnehin nichts anderes machen.

    OK, Deine Dreifach-Pufferung mag etwas bringen, wenn ich 1 Bild/sek darstellen will, und das erste schon in 0.1 sek fertig habe, da hab ich dann für das Zweite 0.9s mehr Zeit (also insg. 1.9s). Aber praktisch sehe ich hier keinen Vorteil, so extrem schwankt die Renderzeit nicht zwischen den Frames, das grade ein Frame mal deutlich länger braucht.
    Ausserdem stelle ich es mir komisch vor, wenn ein Frame 0.1s braucht, ich mit 1fps anzeige und ich nach 1minute schon tausend frames im Vorraus errechne, da haut ja sämtliche Interaktion nicht mehr hin.
    Wiegesagt, soweit ich das verstanden habe (begegnet habe ich es wirklich nocht nicht), will ich damit nur die verschwendete Zeit "warte, bis der Elektrodenstrahl wieder oben-links ist" auffangen, indem ich hier schon weiter mache.
    C++
  • Wenn ich den Swap freigegeben habe, wartet der bei VSync darauf, dass der Elektrodenstrahl (haha) wieder ganz oben links ist. Darum kanns da mal etwas dauern.


    Der Swap Befehl wird bei aktiviertem VSync immer dann automatisch aufgerufen wenn im ersten Backbuffer die Matrize fürs komplette nächste Bild berechnet wurde. Man will das neue Bild ja erst ausgeben wenn es komplett berechnet ist und nicht wenn der Elektronenstrahl das nächste Bild anzeigen möchte.


    Das Beispiel ist vereinfacht und sollte nur aufzeigen was Dreifachpufferung bringt.


    Doppelpufferung ohne VSync -> Tearing bei hoher zu Framerate
    Doppelpufferung mit VSync -> Hoher Performanceverlust, flüssiges Bild

    Dreifachpufferung ohne VSync -> wäre dumm
    Dreifachpufferung mit VSync -> Kein Performanceverlust



    Aber praktisch sehe ich hier keinen Vorteil, so extrem schwankt die Renderzeit nicht zwischen den Frames, das grade ein Frame mal deutlich länger braucht.



    praktische Vorteile sind das es keinen Performanceverlust gibt.

    Wenn ich zB in einem Spiel auf einmal in Echtzeit eine Explosion in Echtzeit berechne dann kann die Renderzeit schonmal etwas höher schießen. Auch wenn die GPUs immer besser werden kann man trotzdem optimieren.



    kann ich das ja nie schaffen


    Das Beispiel ist idealisiert. Es würde bei einer Doppelpufferung extremer ruckeln als mit einer Dreifachpufferung.

    Wenn das eine Bild 3 Sekunden dauert, kann die GPU ohnehin nichts anderes machen.


    Das stimmt, aber wenn es schneller berechnet wird als die Framerate selbst ist, spare ich Zeit und im nächsten Schritt auch wieder Zeit fürs nächste Bild und so weiter und so weiter.


    Ausserdem stelle ich es mir komisch vor, wenn ein Frame 0.1s braucht, ich mit 1fps anzeige und ich nach 1minute schon tausend frames im Vorraus errechne, da haut ja sämtliche Interaktion nicht mehr hin.


    Ich glaube du hast es noch nicht richtig verstanden, was es mit den Puffern auf sich hat. Man kann nicht 1000 Frames im Vorraus berechnen sonern maximal die nächsten 2.

    Ein Buffer = ein Bild
  • neophyte2010 schrieb:

    Der Swap Befehl wird bei aktiviertem VSync immer dann automatisch aufgerufen wenn im ersten Backbuffer die Matrize fürs komplette nächste Bild berechnet wurde. Man will das neue Bild ja erst ausgeben wenn es komplett berechnet ist und nicht wenn der Elektronenstrahl das nächste Bild anzeigen möchte.

    Matrizen? Ich hab hier Code mit 110% GPU-Auslastung und keiner einzigen Matrix :P

    neophyte2010 schrieb:

    Ich glaube du hast es noch nicht richtig verstanden, was es mit den Puffern auf sich hat. Man kann nicht 1000 Frames im Vorraus berechnen sonern maximal die nächsten 2.

    Ja, na klar, war eher als Beispiel gedacht. Bei nur 2 Bildern verschiebt sich das ja auch.

    Probieren wir mal ein Beispiel:
    - Sagen wir, wir haben VSync auf 60Hz, das ist durchaus üblich. Das heisst 60 refreshs die Sekunde, macht also alle 16ms ein Bild.
    - Brauche ich nur 10ms pro Bild, ist alles schön, ich verschenke aber 6ms (Framerate ist flüssig bei 60fps)
    - Brauche ich aber 17ms siehts schlecht aus, meine Framerate halbiert sich, weil ich jeweils zwei Bilder immer doppelt anzeigen muss
    - Steht, wie ich grad sehe, auch so ähnlich bei Wikipedia

    Gehen wir jetzt von Dreifachpufferung aus, P1 (bildschirm) P2 (offscreen1) und P3 (offscreen2)
    Sagen wir mal 8ms pro bild
    Zeit: 0-8: Render nach P3
    Zeit: 8: Swap P3 nach P2 (P2 wartet bis 16)
    Zeit: 8-16: Render nach P3
    Zeit: 16: Swap von P2 auf P1, Swap von P3 auf P2 (P2 wartet bis 32)
    Zeit: 16-24: Render nach P3
    Zeit 24: Kann nicht P2 swappen (wartet bis 32), kann nicht P3 swappen (wartet bis P2 fertig) --> Idle bis 32.
    Haben wir hier was gekonnt?

    Beispiel 2: Rendern bei 24ms pro bild
    Zeit: 0-24: Rendern nach P3
    Zeit: 16: Kein Swap, warten
    Zeit: 24: Swap P3 nach P2
    Zeit: 24-48: Render nach P3
    *Zeit: 32: Swap P2-->P1
    Zeit: 48: Swap P3-->P2 (warten bis 64)
    Zeit: 48-72: Render P3
    *Zeit: 64: P2-->P1
    Zeit: 72: Swap P3-->P2 (warten bis 80)
    Hier haben wir also eine effektive Framerate von wieder 32ms/frame also wieder 30fps also nichts gekonnt?

    Wo mag das was bringen?
    - Vielleicht bei drei Bildern mit 8ms/24ms/8ms. Da können wir das eine 24ms Bild auffedern. Halte ich aber für wenig Praxisrelevant.
    - Bei genau 16ms pro Bild: Ich hab noch ein paar µs mehr Zeit und schaff trotzdem noch mein Vsync
    C++