*Wieder hervorkram*
So
Um das mal zu einem Abschluss zu bringen:
"Damals" im April hatte ich dann das Problem, dass ich Segmentation Faults rein wahllos bekommen habe.
Nach ein bisschen suchen bin ich darauf gekommen, das es KEINEN Lock/Unlock-Mechanismus direkt in OpenSceneGraph gibt.
Also hatte ich das Projekt vorerst auf Eis gelegt.
Jetzt weiß ich nicht, was mich gestern/vorgestern geritten hat, aber ich habs nochmal aufgegriffen
Und zwar wie folgt:
Der Plan war, einen Verbund aus SDL und OSG (wie in diesem Tutorial beschrieben:
http://www.cs.clemson.edu/~malloy/cours ... index.html ) aufzusetzen (also eine GameLoop), und das in einen eigenen Thread zu verbannen.
Anstatt dieses mal jedoch die SDL_Threads zu verwenden, bin ich "klüger" geworden:
OSG selbst unterstützt unterschiedliche ThreadingModelle (das sind Interna). Dazu nutzt es die Bibliothek OpenThreads. Gut, über OpenThreads habe ich erstmal so gar keine Informationen gefunden.
Doch: In der Dokumentation (/usr/share/doc/openscenegraph/) von OSG findet sich auch ein Abschnitt über OpenThreads (genau gesagt eine komplette Referenz).
OpenThreads bildet Threads auf einer rein Objektbasierten-Basis. Das gefiel mir schon mal besser als das Konzept von SDL.
Nach diversen Tests und auch diversen Fehlern (siehe
http://forum.proggen.org/viewtopic.php?p=9289#p9289 ) und einer umfangreicheren Suche als beim letzten mal bin ich zu folgendem Ergebnis gekommen:
OSG und SDL zusammen ist kein Problem.
OSG (Unter Benutzung des Viewers) in einen extra Thread mittels OpenThreads zu schicken ist kein Problem. Probleme kommen erst, wenn auch wirklich gezeichnet und verändert wird.
OSG und SDL zusammen in einen eigenen OpenThreads Thread zu schieben resultiert darin:
http://forum.proggen.org/viewtopic.php?p=9289#p9289 Und zwar egal, wie man es dreht und wendet.^^
Allgemein zu OSG und externen Threads habe ich auch einiges herausgefunden.
Zum einem mal - wie schon angesprochen - hat OSG keinen Lock/Unlock-Mechanismus beim Zeichnen und Ändern des SceneGraphs.
Zumindest in der Art, das man ihn "von außen" erreichen könnte.
OSG selbst ist nämlich in der Lage, Threads zu starten, die genau das vorraussetzen. (aus diesem Grund KÖNNTE es auch gehen, wenn man OSG und OpenThreads verwendet. KÖNNTE!)
Dieses Problem kann man "sicher" umgehen, wenn man den Zeichenvorgang und den Änderungsvorgang in Mutexe setzt.
Code: Alles auswählen
while (!viewer.done())
{
mutex.lock();
viewer.frame();
mutex.unlock();
}
//bei jeder Änderung, die den SceneGraph antastet. Welche das genau sind muss rausgefunden werden.
mutex.lock();
root->attachChild(ieine_node.get());
mutex.unlock();
Das Obige könnte evtl nicht reichen, wenn nämlich der Viewer automatisch eigene Threads startet. Das könnte man unterbinden, das geht aber auch die Performance.
Also evtl noch das folgende einbringen:
Code: Alles auswählen
while (!viewer.done())
{
mutex.lock();
viewer.startThreading();
viewer.frame();
viewer.stopThreading();
mutex.unlock();
}
Ob das nun klug oder performant ist bleibt offen...
Es gibt aber ein viel...unangenehmeres Problem:
Den Zeichen (bzw Event) Thread auszulagern hat keinen Sinn. Der Hauptthread läuft weiter und hat keine Möglichkeit, sinnvoll auf den anderen Thread zu warten.
Somit verliert das alles seinen Sinn^^
Mir bleibt also nur: Lieber über Callbacks und Events arbeiten, als versuchen, die GameLogik in einen eigenen Thread zu bugsieren.
(Wofür aber ein eigener Thread durchaus Sinn macht ist abspielen von Musik)
http://forum.openscenegraph.org/viewtop ... &view=next