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

  • Kira schrieb:

    Wenn jemand tripple-, quad- oder sonstwas buffering haben will macht es doch einfach selbst!

    Einfach in einen eigenen Framebuffer rendern und den als dritten buffer benutzen. Sehe da irgendwie das Problem nicht... das ist nichts was zwingenderweise die GraKa oder der Treiber für einen tun muß.

    Kira

    Du kommst aber nicht an das Vsync Signal. Und selbst wenn, wird es schwer, schnell genug korrekt zu reagieren.
    ♥C++

  • zerm schrieb:

    Du kommst aber nicht an das Vsync Signal. Und selbst wenn, wird es schwer, schnell genug korrekt zu reagieren.


    EInfach anstelle der Scene vor dem SwapBuffers() einfach nur den FBO in den die scene vorher gerendert wurde anzeigen, das geht schnell.. Also die scene immer im hintergrund in nen FBO rendern und dann eben einfach nur diesen rendern bei bedarf.

  • Kira schrieb:

    zerm schrieb:

    Du kommst aber nicht an das Vsync Signal. Und selbst wenn, wird es schwer, schnell genug korrekt zu reagieren.


    EInfach anstelle der Scene vor dem SwapBuffers() einfach nur den FBO in den die scene vorher gerendert wurde anzeigen, das geht schnell.. Also die scene immer im hintergrund in nen FBO rendern und dann eben einfach nur diesen rendern bei bedarf.

    Ja, soweit klar. Aber wie bringt man das mit VSync zusammen?
    ♥C++

  • zerm schrieb:

    Kira schrieb:

    zerm schrieb:

    Du kommst aber nicht an das Vsync Signal. Und selbst wenn, wird es schwer, schnell genug korrekt zu reagieren.


    EInfach anstelle der Scene vor dem SwapBuffers() einfach nur den FBO in den die scene vorher gerendert wurde anzeigen, das geht schnell.. Also die scene immer im hintergrund in nen FBO rendern und dann eben einfach nur diesen rendern bei bedarf.

    Ja, soweit klar. Aber wie bringt man das mit VSync zusammen?

    Darum kümmert sich ja SwapBuffers... ob du jetzt den dritten Buffer via FBO oder der Treiber den intern irgendwie anlegt ist ja egal und macht keinen unterschied. Tendenziell würde der Treiber das intern auch nur als FBO verwalten.

  • Kira schrieb:

    zerm schrieb:

    Kira schrieb:

    zerm schrieb:

    Du kommst aber nicht an das Vsync Signal. Und selbst wenn, wird es schwer, schnell genug korrekt zu reagieren.


    EInfach anstelle der Scene vor dem SwapBuffers() einfach nur den FBO in den die scene vorher gerendert wurde anzeigen, das geht schnell.. Also die scene immer im hintergrund in nen FBO rendern und dann eben einfach nur diesen rendern bei bedarf.

    Ja, soweit klar. Aber wie bringt man das mit VSync zusammen?

    Darum kümmert sich ja SwapBuffers... ob du jetzt den dritten Buffer via FBO oder der Treiber den intern irgendwie anlegt ist ja egal und macht keinen unterschied. Tendenziell würde der Treiber das intern auch nur als FBO verwalten.

    Naja, eben nicht. Soweit ich das Tripple-Buffering verstanden habe (wiegesagt, ich hab das in der Praxis noch nie gesehen), will ich ja grade das Delay zwischen SwapBuffers und VSync auffangen, SwapBuffers wartet (blockiert) ja aber bis zum VSync, also bis der Swap durch ist (?)

    EDIT:
    Das mag ganz interessant dazu sein: forums.nvidia.com/lofiversion/index.php?t169911.html
    ♥C++

  • 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


    Ja bin ich.
    Prinzipiell hast du Recht. Der Vorteil vom triple ist, dass die GPU nicht in der Nase bohren muss, bis das nächste Bild fertig ist. Man könnte es auch so sagen, wenn Du 10 Backbuffer hast, könnte die GPU theoretisch die voll machen, solange der Frontbuffer zu sehen ist.

    Ich selbst hab es noch nie benutzt, bzw. gebraucht, mit DoubleBuffer und eingeschalteten Sync bist zu zunächst vor Tearing sicher. Ich glaube für den Anfang brauchst du dir darum keine Sorgen zu machen.

  • sooo okayse^^war auch nur ne frage mit der Pufferung :D

    hab mich jetz schon weiter in das Buch vertieft hab aber eine nächste Frage.

    kann mir jemand einen Tip geben wie ich in Spielen eine Art physik engine programmiere? zB wenn ich eine Kugel zum Rollen bringen will in einer Kuhle sodass sie wie in echt hin und herrollt. Im Buch wird nur auf Kollisionen eingangen wenn sich objekte berühren. Kann ich das auch mit OpenGL realisieren?

    oder gibt es sowas wie eine OpenSource Physik engine?

  • neophyte2010 schrieb:

    sooo okayse^^war auch nur ne frage mit der Pufferung :D

    hab mich jetz schon weiter in das Buch vertieft hab aber eine nächste Frage.

    kann mir jemand einen Tip geben wie ich in Spielen eine Art physik engine programmiere? zB wenn ich eine Kugel zum Rollen bringen will in einer Kuhle sodass sie wie in echt hin und herrollt. Im Buch wird nur auf Kollisionen eingangen wenn sich objekte berühren. Kann ich das auch mit OpenGL realisieren?

    oder gibt es sowas wie eine OpenSource Physik engine?

    Physik hat nichts mit Graphik zu tun, darum bringt dir OpenGL alleine hier nichts. Du musst, ausgehend von Deiner Geometrie die Physik selber errechnen.
    Hierfür einfach die Differentialgleichungen aufstellen und (diskretisiert) lösen, i.d.R. mit Runge-Kutta Verfahren.
    Fertige Engines (zu empfehlen) sind etwa Bullet, ODE und Newton.
    Bullet ist, soweit ich weiss, im Moment am beliebtesten, da sehr stabil und vielseitig. Newton kommt dafür, wenn ich mich recht erinnere, auch mit Extremsituationen zurecht. Wenn ich eine wählen müsste, würde ich Bullet nehmen, soll einfach sein und wurde so oft empfohlen.

    EDIT:
    Noch ein paar Anmerkungen:
    - Du kannst die Physik natürlich auch "Faken", wenn es sich um einfach Kräfte handelt, das sieht dann nur nicht so realistisch aus.
    - Kollisionserkennung ist ja nur die Erkennung, eigentlich muss es dann noch einen Stoss/Impuls geben etc.
    - Für die sinnvolle Verwendung der Physik-Engines solltest Du zumindest ein grundlegendes Verständnis der zugrunde liegenden Gesetze, Differentialgleichungen und Lösungsverfahren haben, da es schnell passiert, dass Dir (aufgrund numerischer Instabilitäten etwa) alles "explodiert". Dann hilft es, zu wissen, wo man nach dem Fehler suchen muss.

    EDIT2:
    Huch, das ist ja das iPhone Forum. Korrekte Physik in drei Dimensionen wird schnell sehr rechenintensiv, von daher wirst Du evtl. Probleme auf dem iPhone bekommen. Ich weiss auch nicht, ob es (gute) Engines für das iPhone gibt.
    Eventuell willst Du auch in 2D Anfangen, von Box2D habe ich auch schon einiges Gutes gehört/gesehen.
    ♥C++

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

  • zerm schrieb:



    EDIT2:
    Huch, das ist ja das iPhone Forum. Korrekte Physik in drei Dimensionen wird schnell sehr rechenintensiv, von daher wirst Du evtl. Probleme auf dem iPhone bekommen. Ich weiss auch nicht, ob es (gute) Engines für das iPhone gibt.
    Eventuell willst Du auch in 2D Anfangen, von Box2D habe ich auch schon einiges Gutes gehört/gesehen.



    Ich möchte ein 2D Spiel erstellen welches aber eine Physik besitzt.


    Danke erst einmal für die Antwort, werd ich mich mal weiter um das Thema schlau machen.


    //EDIT

    Bin gerade auf eine 2D Enginge aufmerksam geworden namens Cocos2D welche wohl speziell fürs Iphone ist.
    sieht gut aus: Youtube

    muss nur rausbekommen wie ich das jetzt miteinander verknüpfe

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