Fehler [WEOpenGLView idle]

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

  • Fehler [WEOpenGLView idle]

    Hallo, ich schon wieder, ist mir peinlich.
    Wenn ich das Programm starte, ist der view mit desktop-Schnipseln gefüllt und ich bekomme die Nachricht:
    -[WEOpenGLView idle:]: unrecognized selector sent to instance 0x1d3b0030

    Die Instanz ist WEOpenGLView. Die initWithFrame: Methode wird nicht ausgeführt, wohl aber
    awakeFromNib und prepareOpengl . Ich hab es auch so eingerichtet, dass der VBO und FBO relevante
    code nicht angesteuert wird, hat auch nichts gebracht.
    The masters make the rules for the wise men and the fools

  • probier mal das

    Quellcode

    1. @interface WEOpenGLView : NSView


    BTW: Der Code ist nicht gerade schön

    Quellcode

    1. NSOpenGLPixelFormat* pixelFormat = [[[NSOpenGLPixelFormat alloc]
    2. initWithAttributes:attribsBasic] autorelease];
    3. self = [super initWithFrame:frame pixelFormat:[pixelFormat autorelease]];


    Quellcode

    1. - (void) awakeFromNib
    2. {
    3. colorMaterial = [[VRGLServices alloc]init];


    für was ist das ??

    Quellcode

    1. glBufferData(GL_ARRAY_BUFFER, size, [dat bytes], GL_DYNAMIC_DRAW);
    2. else
    3. glBufferData(GL_ARRAY_BUFFER, size, [dat bytes], GL_STATIC_DRAW);

  • mit den Desktop-Schnippseln einmal wild geraten:

    Quellcode

    1. glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    2. [[self openGLContext] makeCurrentContext];

    in der anderen Reihenfolge, sonst wird das Clear evtl. nicht auf dem korrekten Kontext ausgefuehrt.


    Das BufferData Zeug sieht mir im Uebrigen korrekt aus, keine Ahnung, was wolf da hat...Und zum Rest kann ich hier grad nix sagen..
    ♥C++

  • Original von wolf_10de
    Die initWithFrame wird für ein OpenGLView nicht aufgerufen, folglich geht alles was da drin steht incl. Context und Pixelformat in die Hose.

    Mhh diese daemlichen NSOpenGLViews. Zuhause fuer ein Projekt habe ich auch alles in ein normales NSView verpackt. Naja, ein ScrollView+ClipView+NSView.
    Apropos, zu NSScrollViews+NSClipViews hab ich nochmal eine Frage, aber verdammt, mein Code ist zuhause :)
    ♥C++

  • Original von zermelo
    mit den Desktop-Schnippseln einmal wild geraten:

    Quellcode

    1. glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    2. [[self openGLContext] makeCurrentContext];

    in der anderen Reihenfolge, sonst wird das Clear evtl. nicht auf dem korrekten Kontext ausgefuehrt.


    Das BufferData Zeug sieht mir im Uebrigen korrekt aus, keine Ahnung, was wolf da hat...Und zum Rest kann ich hier grad nix sagen..


    Wenn sich die Daten oft ändern genügt die Angabe von GL_DYNAMIC_DRAW. Ich behaupte mal das das ständige Änderung der Modi mehr Zeit (reorganisation) braucht als es bringt.

    GL_STAIC_DRAW, bietet sich an, wenn sich die Daten nur wenig oder gar nicht ändern.

  • Original von zermelo
    Original von wolf_10de
    Die initWithFrame wird für ein OpenGLView nicht aufgerufen, folglich geht alles was da drin steht incl. Context und Pixelformat in die Hose.

    Mhh diese daemlichen NSOpenGLViews. Zuhause fuer ein Projekt habe ich auch alles in ein normales NSView verpackt. Naja, ein ScrollView+ClipView+NSView.
    Apropos, zu NSScrollViews+NSClipViews hab ich nochmal eine Frage, aber verdammt, mein Code ist zuhause :)


    Was ist daran schlimm, ist doch gut wenn man eben schnell mal was basteln will.

  • Original von wolf_10de
    Original von zermelo
    mit den Desktop-Schnippseln einmal wild geraten:

    Quellcode

    1. glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    2. [[self openGLContext] makeCurrentContext];

    in der anderen Reihenfolge, sonst wird das Clear evtl. nicht auf dem korrekten Kontext ausgefuehrt.


    Das BufferData Zeug sieht mir im Uebrigen korrekt aus, keine Ahnung, was wolf da hat...Und zum Rest kann ich hier grad nix sagen..


    Wenn sich die Daten oft ändern genügt die Angabe von GL_DYNAMIC_DRAW. Ich behaupte mal das das ständige Änderung der Modi mehr Zeit (reorganisation) braucht als es bringt.

    GL_STAIC_DRAW, bietet sich an, wenn sich die Daten nur wenig oder gar nicht ändern.

    Beim Ueberfliegen des Codes hatte ich es so verstanden, dass wenn er eine Animation laed, er das ganze auf DYNAMIC_DRAW setzt und sonst eben auf STATIC; hab nich gesehen, ob das oefter als einmal aufgerufen werden soll...
    ♥C++

  • Zuerst einmal, danke für eure Anteilnahme.

    Das FBO und VBO Zeugs habe ich mal von ADC bekommen, als ich noch Geldfür die Kirchensteuer hatte. Das ist auch schon mal gelaufen, nur war mein Teil an dem Projekt so schlecht, dass ich nochmal angefangen habe.

    Wenn sich die Daten oft ändern genügt die Angabe von GL_DYNAMIC_DRAW. Ich behaupte mal das das ständige Änderung der Modi mehr Zeit (reorganisation) braucht als es bringt.


    Der einzige relevante Teil von mir ist die Unterscheidung STATIC / DYNAMIC, weil der überwiegende Teil der Grafik statisch ist.

    probier mal das

    Quellcode

    1. @interface WEOpenGLView : NSOpenGLView

    Ich muss also den NSOpenGLView im IB durch NSView ersetzen.

    btw, der IB ist auch nicht erste Sahne. Wenn man da, aus Unkenntnis einen Fehler macht, das verzeiht er nicht. Beispiel SnowLeopard (lass' ich erstmal beiseite). Wenn ich einen OpenGLView instantiiere, werde ich informiert, dass der nicht erlaubt ist, wenn one-shot im Fenster aktiviert ist. wenn ich dann one-shot deaktivere, expandiert er den view auf das gasamte Fenster.

    Schliesslich bleibt noch die Frage: Wer hat da einen @selector an meinen view geschickt ? IB ?
    Ich jedenfalls nicht, nicht in diesem Stadium der Entwicklung.
    The masters make the rules for the wise men and the fools

  • Original von VanceRegnet
    Zuerst einmal, danke für eure Anteilnahme.

    Das FBO und VBO Zeugs habe ich mal von ADC bekommen, als ich noch Geldfür die Kirchensteuer hatte. Das ist auch schon mal gelaufen, nur war mein Teil an dem Projekt so schlecht, dass ich nochmal angefangen habe.

    Wenn sich die Daten oft ändern genügt die Angabe von GL_DYNAMIC_DRAW. Ich behaupte mal das das ständige Änderung der Modi mehr Zeit (reorganisation) braucht als es bringt.


    Der einzige relevante Teil von mir ist die Unterscheidung STATIC / DYNAMIC, weil der überwiegende Teil der Grafik statisch ist.

    probier mal das

    Quellcode

    1. @interface WEOpenGLView : NSOpenGLView

    Ich muss also den NSOpenGLView im IB durch NSView ersetzen.
    .


    Jepp

  • Ich hab' den NSView im IB iinstatiiert, das fehlerhafte Verhalten ist geblieben, bis auf die Tatsache,
    dass -initWithFrame: nun ausgeführt wird.
    Wenn euch nichts mehr einfällt, muss ich wohl von vorne anfangenhttp://www.osxentwicklerforum.de/images/smilies/frown.gif
    The masters make the rules for the wise men and the fools

  • Original von VanceRegnet
    Genau das hab' ich getan und dabei den Fehler gerfunden. Ich darf weder in -awakeFromNib noch
    in -prepareOpenGL eien setter verwenden. Wenn ich schreibe

    Quellcode

    1. allowMovie = NO;

    dann geht's.
    Bin ich froh !


    Das kannst du ja nicht pauschal sagen, in der awakeFromNib steht (bei eine OpenGLView) noch kein Context, folglich darfst du dort keine OpenGL-Aufrufe machen.
    Die prepareOpenGL ist der richtige Platz dafür (aber wieder auch nur für ein OpenGLView)

    Wenn du ein normales View nimmst ist das etwas anderes. in der InitWithFrame legst du einen Context und ein Pixelformat an, dann kannst du in der awakeFromNib OpenGL-Aufrufe machen. Du siehst es kommt drauf an, was für ein View du nimmst.

    Ich hab im Buch beide Versionen gezeigt

  • Original von VanceRegnet
    Genau das hab' ich getan und dabei den Fehler gerfunden. Ich darf weder in -awakeFromNib noch
    in -prepareOpenGL eien setter verwenden. Wenn ich schreibe

    Quellcode

    1. allowMovie = NO;

    dann geht's.
    Bin ich froh !


    Achso halt, das hat damit nix zu tun, das Problem bei dir ist wohl das self, da es kein self gibt (kein initWithFrame). Prüf das nochmal

  • Zu früh gefreut,
    wenn ich das Projekt öffne und starte oder nach einer build phase zeigt sich wieder der verkleckerte view.
    Wenn ich dann das Programm zu wiederholtem Mal starte ist es in Ordnung (Das Produkt auch)).

    Ich meine, dieser Fehler ist von allgemeinem Interesse (besonders für Masochisten).
    Ich hab' das Projekt (ohne openGL und QTKit framework) angehängt.
    The masters make the rules for the wise men and the fools