Reihenfolge OpenGl

[EWeiss]

Habe da ne frage was die initialisierung und funktion von OpenGl in dieser Reihenfolge angeht

Anwendung übergibt nur das Handle eines Panel als Beispiel.
Dieses wird an eine DLL übergeben welche vorher OpenGl initialisiert
und dann das Panel zu Zeichenfläsche für OpenGl funktionsfähig macht (machen soll).

Diese DLL läd dann ein OpenGl Plugin welches dann Daten zum Rendern zur verfügung
gestellt bekommt um seine Visualisierung anzuzeigen.

Meine Frage deshalb funktioniert das überhaupt ?
Bekomme hier immer den gleichen Fehler Access Violation ntdll.dll kann da auch nichts debugen
oder an den Fehler etwas ändern da er von den in PowerBasic geschriebenen Plugins kommt.


Das ganze läuft so ab!
Anwendung schickt das Handle von Panel und weist es
BB_VisDataThread.Handle zu.

Mit diesen wird nun das Panel OpenGl fähig gemacht. (sollte zumindest)
Anschließend wird die Message BBP_CREATE gesendet welche Titel,Version usw.. zurückgibt.
Ist das erfolgreich schicke ich dem Plugin die neuen Daten.
Das ParentWindow Handle h_DC usw..

Delphi-Quellcode:

    if (BassBoxInfo^.Init) then
    begin
      // OpenGL-Funtionen initialisieren
      if not InitOpenGL then
        Halt;

      // Gerätekontext holen
      h_DC := GetDC(BB_VisDataThread.Handle);
      // Renderkontext erstellen (32 Bit Farbtiefe, 24 Bit Tiefenpuffer, Doublebuffering)
      h_RC := CreateRenderingContext(h_DC, [opDoubleBuffered], 32, 32, 0, 0, 0, 0);
      // Erstellten Renderkontext aktivieren
      ActivateRenderingContext(h_DC, h_RC, true);

      BassBoxInfo^.Msg := BBP_CREATE;
      if BBP_Plugin(BassBoxInfo^) = BBP_SUCCESS then
      begin

        BassBoxInfo^.Msg := BBP_INIT;
        BassBoxInfo^.ParentWindow := BB_VisDataThread.Handle;
        BassBoxInfo^.DC           := h_DC;
        BassBoxInfo^.rc           := h_RC;
        BassBoxInfo^.BackARGB     := 0; //SK_AEROCOLOR()
        BassBoxInfo^.FFTsize      := 256;
      end;

      if BBP_Plugin(BassBoxInfo^) = BBP_SUCCESS then
      begin

Bei zwei Plugins funktioniert das..
Hier eins davon die BBP_INIT.

Code:

    CASE %BBP_INIT
         '// Do your code initialisation there

         CALL BBP_SplitColorARGB(BBP.BackARGB, A?, R?, G?, B?)
         Alpha! = A? + 1: Red! = R? + 1: Green! = G? + 1: Blue! = B? + 1
         Call glClearColor(red! / 256, green! / 256, blue! / 256, alpha! / 256)

         CALL glEnable(%GL_DEPTH_TEST)
         CALL glShadeModel(%GL_SMOOTH)

         Call ColorInit

das ist alles was ausgeführt wird und mit OpenGl bei der initialisierung zu tun hat.
Visualisiert wird nix da ich die Message BBP_RENDER noch nicht geschickt habe.
Wird die geschickt dann habe ich ein schwarzes Panel sonst aber nix.

Die anderen welche nicht gehen.
Auch ein Beispiel!

Code:

    CASE %BBP_INIT
         '// Do your code initialisation there
         Call ColorInit

         CALL BBP_SplitColorARGB(BBP.BackARGB, A?, R?, G?, B?)
         Alpha! = A? + 1: Red! = R? + 1: Green! = G? + 1: Blue! = B? + 1
         Call glClearColor(red! / 256, green! / 256, blue! / 256, alpha! / 256)

         CALL glShadeModel(%GL_SMOOTH)
         Call glClearDepth(1#)         '// Depth Buffer Setup
         CALL glBlendFunc(%GL_ONE, %GL_ONE)
         CALL glDepthFunc(%GL_LESS)    '// The Type Of Depth Test To Do
         CALL glDisable(%GL_LIGHTING)
         CALL glEnable(%GL_BLEND)
         CALL glAlphaFunc(%GL_GREATER, 0.01)
         CALL glHint(%GL_PERSPECTIVE_CORRECTION_HINT, %GL_NICEST)

         CALL glEnable(%GL_TEXTURE_2D)

         Randomize GetTickCount()

         mt(1).FullName = $BBP_PLUGIN_FOLDER + "Texture\Flare0.jpg":  mt(1).ID = 1: mt(1).Square = 0
         mt(2).FullName = $BBP_PLUGIN_FOLDER + "Texture\BassBox.png":  mt(2).ID = 2: mt(2).Square = 0
         Call MakeMutipleTexture(ByVal VarPtr(mt(LBound(mt))), UBound(mt) - LBound(mt) + 1)

         'UseFont.fontName = "Arial"
         'UseFont.fontHeight = 10
         'UseFont.fontWeight = %FW_BOLD
         'CALL BBP_BuildGLfont(BBP.DC, UseFont) ' Build OpenGL font for our OpenGL window

         Call MakeColorLUT
         GoSub ResetCXCYCZ

funktionieren überhaupt nicht.
Sobald ich die Initialisiere kommt der schon genannte Fehler..
Nun meine frage ist das mit so einer ablauffolge überhaupt möglich da was auf die reihe zu bekommen ?

Habe leider kein PowerBasic so das ich das selbst mal debugen könnte was da so abgeht.

gruss Emil

PS:Wenn's generell nicht geht kann ich mir die Arbeit sparen.

[Lossy eX]

Zitat von EWeiss:

BB_VisDataThread

Arbeitest du mit unterschiedlichen Threads? Du kannst nicht in Thread A den Kontext erstellen und in B dann zeichnen. Evtl mag es gehen, wenn du ActivateRenderingContext in dem anderen Thread (B) noch mal aufrufst aber da muss ich selber gestehen, dass ich das noch nie gemacht habe. Bzw wglMakeCurrent wird nur innerhalb von ActivateRenderingContext aufgerufen.

[EWeiss]

Zitat von Lossy eX:

Zitat von EWeiss:

BB_VisDataThread

Arbeitest du mit unterschiedlichen Threads? Du kannst nicht in Thread A den Kontext erstellen und in B dann zeichnen. Evtl mag es gehen, wenn du ActivateRenderingContext in dem anderen Thread (B) noch mal aufrufst aber da muss ich selber gestehen, dass ich das noch nie gemacht habe. Bzw wglMakeCurrent wird nur innerhalb von ActivateRenderingContext aufgerufen.

Die initialisierung des Opengl contex erfolgt in einer Funktion außerhalb
des RenderThreads anders gehts wohl nicht.
Rufe ich ActivateRenderingContext innerhalb der Renderfunktion fortlaufend auf ist der Speicher schnell voll.

Glaube langsam das es einfach nicht machbar ist.

gruss Emil

[Lossy eX]

Ich habe aber gerade mal geschaut. Du kannst den RC innerhalb eines Threads erstellen und in der VCL benutzen. Damit handelt es sich um 2 unterschiedliche Threads was ja der Thematik entspricht. Also folgendes. Nach dem Erstellen, wird der RC ja normal aktiviert. Damit wäre er an diesen Thread "geknebelt". Diesen RC kannst du dann in keinen anderen Thread aktivieren und somit steht in den Threads kein OpenGL zur Verfügung. Aber nur solange er noch aktiv ist.

Du müstest dann den RC entweder in dem Thread entbinden wglMakeCurrent(DC, 0); oder aber du aktivierst ihn gar nicht erst im Thread sondern nur wärend dem Rendern.

Du musst aber aufpassen, dass du die Funktionspointer lädst. Also ActivateRenderingContext mit dem dritten Paramater True. Nur nicht jedes mal wärend dem Rendern, da es sonst viel zu langsam werden würde! Da würde sich wohl eine Variablen empfehlen mit der überprüfst ob der RC bereits aktiviert ist. Wenn nicht. Aktivieren und funktionspointer laden. Anschließend die Variable setzen damit er nicht noch einmal aktiviert wird. Denn selbst das Aktivieren eines RCs dauert einiges an Zeit. Weswegen man das sehr sparsam machen sollte.

[edit] Es scheint wohl auch so zu sein, dass die Lebensdauer des RCs von der Lebendauer des Erstellerthreads abhängt. Wird der Thread zerstört ist der RC futsch. Selbst wenn er nicht in dem Thread aktiviert wurd/ist. Ich will also auch nicht ausschließen, dass es sonst keine Probleme mehr gibt.

[EWeiss]

Versteh jetzt nicht ganz was du meinst
Ich initialisiere den RC nur einmal wenn das Plugin aktiviert wird.

Was ich feststellen muss ist das sich das hdc ständig verändert.
Deshalb muss ich von außen den dc manuell über die Render Function zufügen.

Delphi-Quellcode:

        BASSVIS_RenderToDC(mVisParam.Kind,
                                       mVisparam.VisHandle,
                                       @WaveData,
                                       @FFTData,
                                       dc,
                                       BASS_SAMPLE_MONO, StreamPos)

was das nun mit dem RC zu tun hat keine ahnung der ändert sich ja nicht.

gruss Emil

[Lossy eX]

Also ich muss ehrlich gestehen, dass ich dachte ich wüsste was du tust. Bis eben. Könntest uns evtl. mal genau erklären was du da mit bass machst und wo die Threads zustanden kommen?

[EWeiss]

Zitat von Lossy eX:

Also ich muss ehrlich gestehen, dass ich dachte ich wüsste was du tust. Bis eben. Könntest uns evtl. mal genau erklären was du da mit bass machst und wo die Threads zustanden kommen?

Kann ich machen obwohl das eigentlich schon erklärt wurde.
Meine EXE verwendet eine DLL welche externe Visual Plugins läd.
Die neue Plugin gruppe die von BassBox verwendet wird erwartet das ich in meiner DLL OpenGl Initialisiere
und diverse andere functionen an die Plugins schicke damit diese mit OpenGl zusammen arbeiten können.

der Container für OpenGl ist ein Panel in der Exe welches über meine DLL OpenGl fähig gemacht wird.

Um was es mir geht ob es überhaupt vernünftig läuft wenn das über 3 verschiedene Anwendungen läuft.
Bisher habe ich zumindest festgestellt das sobal eine Texture innerhalb des VisPlugin initialisiert (geladen wird)
meine DLL bzw.. die Anwendung beendet mit der Meldung ntdll.dll access Violation.

gruss Emil

Im anhang ein Pic was da gerendert wird kommt vom Plugin
Meine EXE startet den Plugin Wrapper und das Panel wird OpenGl fähig gemacht.

[Lossy eX]

Ja okay. Das hab ich jetzt auch verstanden. Danke. Aber wo kommen deine Threads zu stande? Denn wenn du ohne Threads arbeiten würdest wäre es egal wie viele DLLs es sind. Ich habe auch eine DLL geschrieben die über eine Schnittstelle OpenGL benutzt. Und da kommt sich nichts in die Quere. Ich bleibe aber bei einem Thread.

Threads und OpenGL bzw VCL sind halt auch nicht ungefährlich. Da kann es immer zu Problemen kommen. Deswegen sollte das zu mindest auf ein Minimum reduziert werden.

[EWeiss]

Zitat von Lossy eX:

Ja okay. Das hab ich jetzt auch verstanden. Danke. Aber wo kommen deine Threads zu stande? Denn wenn du ohne Threads arbeiten würdest wäre es egal wie viele DLLs es sind. Ich habe auch eine DLL geschrieben die über eine Schnittstelle OpenGL benutzt. Und da kommt sich nichts in die Quere. Ich bleibe aber bei einem Thread.

Threads und OpenGL bzw VCL sind halt auch nicht ungefährlich. Da kann es immer zu Problemen kommen. Deswegen sollte das zu mindest auf ein Minimum reduziert werden.

Schau es dir einfach an...
2 Plugins gehn da sie keine Texturen verwenden

MagicD und Micado

um die anderen zu testen mußt du einfach den texture Ordner umbenennen.
Wie gesagt mit Texturen kommt ein ntdll.dll Error kann nicht sagen ob er
durch meine DLL oder die Visplugins zustande kommt.

gruss Emil

[Lossy eX]

Okay. OpenGL scheint ja dann so halb zu funktionieren. Allerdings bin ich mir trotzdem nicht im Klaren wo welcher Thread zum Einsatz kommt. Denn um meine Bedenken etwas weiter auszuholen. Wenn du aus einem anderen Thread auf die VCL zugreifst, dann kann es zu unerklärlichen Problemen kommen. Wenn man aus verschiedenen Threads mit Bitmaps arbeitet, dann kann es sein, dass die irgendwann den Dienst verweigern. OpenGL ist auch sehr stark von den Threads abhängig. Alles in allem ist die GDI, VCL nicht Threadsave und OpenGL ist mehr oder weniger indirekt an einen Thread gebunden.

Eine Möglichkeit da auf die Threads zu verzichten gibt es rein zufällig nicht? Denn das würde in jedem Fall einiges einfacher machen. Aber ich kann nicht abschätzen ob das Technisch überhaupt möglich ist. Ich habe es nur selber immer wieder mitbekommen, dass es immer irgendwo welche Probleme gibt.