Merkwürdige Probleme bei Windows Migration (DevIL)

[Hellhound]

Hallo zusammen,

wie ich bereits in in diesem Thread http://zfx.info/viewtopic.php?f=4&t=864#p10570 beschrieben habe bin ich aktuell mit der Migration unserer Linux Sourcen nach Windows beschäftigt. Dank Kimmi konnte ich auch das letzte Problem lösen, nun habe ich als Windowstheniker ;) Probleme bei der Migration, die ich mir nicht erklären kann und Hoffe Ihr könnt einem DAU wie mir da weiterhelfen ...

Ich kann nun inzwischen erfolgreich die DevIL Bibliothek linken, bauen und kompillieren. Das ganze mache ich in einem separaten Modul (brGraphics), das nach dem Linken als libbrGraphics.dll und libbrGraphics.dll.a ablege. Soweit so gut. Klappt auch. Rufe ich nun jedoch aus irgend einer Klasse, den DevIL Loader in diesem Modul auf (In CMake als LIBRARY Dependency verlinkt), dann bekomme ich für jeden ilGetInteger Aufruf 0 zur Laufzeit zurück ...

Der gesamte Code läuft fehlerfrei unter Linux (hier werden natürlich nur .a Libraries des Moduls erzeugt) und unter WindowsXP. Auf meiner 32 bit Vista Kiste läuft es nicht ... Erst dachte ich, es liegt evtl. an Vista, aber wenn ich das gleiche CMake-Skript nutze um out of the box (d.h. ohne das Modul in einer einfachen Main-Test Klasse) laufen lasse läuft der Code auch unter Vista ... Verstehe den Zusammenhang nicht ...

Ich vermute irgendwie einen Fehler i.Z.m. DLL's, evtl. irgendwo im Zugriff. Weiß hier aber nicht weiter (Ein explizite dll EXPORT Deklaration der Klassen brachte keinen Erfolg, gleicher Fehler) und kenne mich unter Windoof nicht so aus.

Weiß hier jemand zufällig Rat? Ich bin dankbar für jeden Tipp.
Gruß
Christian

[kimmi]

Heißt was? Ich habe dein problem noch nicht vollständig verstanden? Kannst du die Bilder nicht laden beziehungsweile wenn du auf Daten eines Bildes zugreifen möchtest? Oder kannst du prinzipiell keine Funktionsaufrufe in DeVIL benutzen, weil du einen Runtimefehler gekommst? Kannst du da mal zeigen, wie du das Ganze benutzt ( also im Code ) ?

Gruß Kimmi

[Hellhound]

Hmm, nicht ganz so einfach, da es doch viel Code ist. Aber ich gebe mal mein Bestes.
Also hier der Code aus der decode Methode des brDevILImageCodec zum Laden der Bilder:

Code: Alles auswählen

   ILuint ilImage = 0;
   boost::shared_ptr<brImage> image;
   std::vector<unsigned char>*	imageData = new std::vector<unsigned char>();

   // This defines the Origin to regard OpenGL texture format with the origin as lower left corner.
   // Other formats normally use upper left corner as origin (i.e. DirectX). Check if this is required
   // or any BinRev texture definition should follow the normal way with upper left corner
   ilOriginFunc(IL_ORIGIN_LOWER_LEFT);
   ilEnable(IL_ORIGIN_SET);
  
   ilGenImages(1, &ilImage);
   ilBindImage(ilImage);

   if (!ilLoadImage(const_cast<const ILstring>(path.c_str())))
   {
      ilDeleteImages(1, &ilImage);
      throw brCore::brIllegalStateException("[brDevILImageCodec]::decode: Could not load image: " + path);
   }

   ILint ilType = ilGetInteger(IL_IMAGE_TYPE);
   ILint ilFormat = ilGetInteger(IL_IMAGE_FORMAT);
   brPixelFormat format = this->getPixelFormat(ilFormat, ilType);

Das ganze läuft durch bis zu den Aufrufen ILint ilType = ilGetInteger(IL_IMAGE_TYPE); und ILint ilFormat = ilGetInteger(IL_IMAGE_FORMAT); die liefern zur Laufzeit nur unter Windows Vista (32bit) immer 0 zurück, unter Windows XP und Linux (Debian) läuft es und ich bekomme das korrekte Format + Typ zurückgegeben. Die Klasse selbst befindet sich im brGraphics (MODULE_NAME) modul, aus dem ich mit CMake eine Lib erzeuge:

Code: Alles auswählen

#Link required Libraries requires CMake 2.6
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} GREATER 2.5)
	ADD_DEPENDENCIES(${MODULE_NAME} brConfig brMath)
	TARGET_LINK_LIBRARIES(${MODULE_NAME}
                            brCore 
                            brConfig 
                            brMath 
                            ${BOOST_SIGNAL}
                            ${IL_LIBRARY}
                            ${ILU_LIBRARY}
                        )	
ENDIF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} GREATER 2.5)

#Install of other files requires CMake 2.6
IF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} GREATER 2.5)
      INSTALL(TARGETS ${MODULE_NAME} DESTINATION lib)
      INSTALL(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} DESTINATION include/BinRev FILES_MATCHING PATTERN "*.h")
ENDIF (${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} GREATER 2.5)

In meiner Demoklasse rufe ich lediglich den DevILCodec auf und dann knallt es zur Laufzeit, weil die Werte 0 sind:

Code: Alles auswählen

 brGraphics::brDevILImageCodec codec = brGraphics::brDevILImageCodec();
     boost::shared_ptr<brGraphics::brImage> image = codec.decode("data/textures/testTexture.png");

Und gebunden wird das brGraphics Modul in der CMake Datei für das demofile:

Code: Alles auswählen

add_executable (win32Texture_demo demo_win32Texture.cpp)
ADD_DEPENDENCIES(win32Texture_demo brGraphics brConfig brRenderer)
TARGET_LINK_LIBRARIES(win32Texture_demo brConfig brGraphics brRenderer)

Ich hoffe ich konnte damit Deine Fragen klären... Der Code zu meinem Out of the box Demo ist identisch was den
Ladeprozess angeht. Einziger Unterschied ist die Nutzung der DevIL Bibliothek. Anstelle sie wie hier indirekt über
das brGraphics modul zu beziehen, binde ich sie dort direkt im CMake Skript.

Code: Alles auswählen

SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(IL_INCLUDE_DIR /c/binrev/development/mingw/include)

INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR} 
    			  ${CMAKE_CURRENT_SOURCE_DIR}/src 
    			  ${DEVIL_INCLUDES}
			  /usr/include 
			  /usr/local/include 	             
)

add_executable (DevILTest ${Sources})
SET(EXECUTABLE_OUTPUT_PATH/bin ${CMAKE_SOURCE_DIR})
TARGET_LINK_LIBRARIES(DevILTest ${OPENGL_LIBRARIES} ${IL_LIBRARY})

Daher meine Vermutung, das etwas mit der Libraryanbindung schief läuft ...

[kimmi]

An welcher Stelle wird welche Variable 0 ( die genaue Codezeile )? Das sehe ich gerade nicht :).

Gruß Kimmi

[Hellhound]

Folgendes liefert nur 0 zurück:

Code: Alles auswählen

ILint ilType = ilGetInteger(IL_IMAGE_TYPE);
ILint ilFormat = ilGetInteger(IL_IMAGE_FORMAT);

Ich habe auch testhalber noch mal die übrigen Aufrufe geprüft, auch alle anderen ilGetInteger Aufrufe
liefern nur 0 Werte unter Vista zurück (Code im letzten Snipped nicht enthalten):

Code: Alles auswählen

 image->setWidth(ilGetInteger(IL_IMAGE_WIDTH));
   image->setHeight(ilGetInteger(IL_IMAGE_HEIGHT));
   image->setBpp(ilGetInteger(IL_IMAGE_BITS_PER_PIXEL));
   image->setNumberOfMipmaps(ilGetInteger (IL_NUM_MIPMAPS));

[Hellhound]

Hmm, ich glaube immer mehr das es irgendwie mit den Dlls zusammenhängen muß. Inzwischen habe ich herausgefunden,
dass Widnows Dlls nen bissl anders arbeiten als Linux libs. D.h. Singletons und statische Variablen in einer DLL sind wohl
nicht ganz so einfach umzusetzen wie unter Linux ... Scheinbar macht jede dll ihre eigene Instanz eines Objektes auf,
wodurch echtes sharing nicht so einfach möglich ist...

Das erklärt bei mir einiges an merkwürdigem Verhalten (Singletons liefern unter Windows keine Werte zurück, wenn ich
sie aus einem anderen Modul heraus aufrufe, obwohl Werte gesetzt worden sind). Kann dies auch die Nutzung der DevIL
Lib beeinflussen?

Hab es noch mal out of the box getestet, d.h. ohne dlls, da läuft es fehlerfrei ... gnarf ...

[kimmi]

Singeltons würde ich im wesentlichen versuchen zu vermeiden. Dazu schau mal nach, ob du überall dynamisch gelinkt hast ( also keine statische Lib versehentlich mit dabei hast ). Wenn du irgendwo durch eine statisch gelinkte Lib mehrfach deine Singleton-Instanz ( statisch ) gelikt hast, können solche Effekte auftreten. Dazu kannst du dir die Stelle auch im Debugger ansehen. Werden im Output-Fenster irgendwelche merkwürdigen Nachrichten protokolliert, bevor deine Anwendung abschmiert?

Gruß Kimmi

[Hellhound]

Jetzt kann ich Dir grad nicht mehr folgen. Also unter linux sind das shared Libraries, die zur link Zeit angezogen werden.

Code: Alles auswählen

Linking CXX shared library ../../lib/libbrCore.dll
Creating library file: ../../lib/libbrCore.dll.a

Was CMake da unter Windows draus macht, ist mir aktuell nicht mehr klar, hab ja am Skript nix verändert aber eigentlich
müssten es ja laut output shared libs sein. Ich erhalte xxx.dll und xxx.dll.a Libs aber ob die statisch oder dynamisch sind k.A. ...
Ich brauche eigentlich nur shared lib Verhalten ...

Und nein es gibt keinen merkwürdigen Output in der Konsole. Der Crash wird ja von mir provoziert (Exeption) weil ich
keien gültigen Werte mehr habe um weiter zu arbeiten...

[kimmi]

Ganz blöde Frage: hast du die jpg-Dll bei deinen Devil-Dlls rumliegen ( wenn du jpg benutzen solltest )?

Gruß Kimmi

[Hellhound]

Benutze aktuell keine jpg Dateien, teste mit png, bmp, tga. Aber unter Windows XP, Linux und out of the box tests laufen auch jpg
Dateien.

[kimmi]

Liegen die entsprechenden Dlls für die Bildformate herum? Beziehungsweise: lädt Devil die Formate über die jeweiligen Dlls ( also benötigt Devil zum Laden eine png-Bildes die pg.dll )? SDL-Image benötigt diese. Liegt also für einen png-Import nicht die zugehörige png.dll irgendwo im Suchpfad für Dlls herum, scheitert der Import des Bildes und überall wird 0 zurückgegeben.

Gruß Kimmi

[Hellhound]

Nein DevIL benötigt keine separaten image libraries, die sind mit enthalten. Läuft ja auch out of the box, nur im Framework nicht, wo ich eine dll refernziere.

Denke nach wie vor es liegt an den Libs (dll's) die generiert werden auch wenn sie shared sind. Stutzig macht mich grad eine andere Stelle, wo ich ein einfachen ConfigManager habe. Dieser ist ein Singleton und wird in eine brConfig.dll gebaut. In meiner Demo Klasse und in der brGraphics dll refernziere ich dieses Singleton. Setze ich in meiner Testklasse Values am Singleton, dann erhalte ich keine Werte in meiner anderen brGraphics dll. Vermutlich weil Wingrüze ggü. Linux kein Memory-Sharing zwischen den dll's erlaubt und ich somit in meiner Testklasse eine andere Objektinstanz habe als in meiner dll ... Schau mir grad noch die dllexport/dllimport Funktionen von Windoof an, vielleicht kann ich damit das Problem umgehen, steige da aber aktuell noch nicht so durch ...

Und vielleicht ist auch dass ein Problem das sich auch auf die DevIL Geschichte auswirkt. Ich werde mal schauen ob ich irgendwo nen upload Platz finde und dort mal die Sourcen für das out of the box Beispiel und ein sehr stark redzuiertes dll Beispiel einstelle, damit Du Dir mal nen näheres Bild von dem ganzen machen kannst ... Kann aber etwas dauern ...

[kimmi]

Singletons, wenn richtig implementiert, funktionieren unter Windows über dl-Grenzen hinweg. Wir machen das in der ZFXCE für das Logging und da haben wir keine Probleme. Mischt man allerdings static-Libs und Dlls, kann es solche Probleme geben. Aber das ist nur eine mögliche Ursache. Das Beste ist es da, einfach mal in die Devil-Funktionen reinzudebuggen und nachzuschauen, was nicht funktioniert.

Gruß Kimmi

[Hellhound]

So das Problem ist gelöst. Frag mich bitte nicht was anders ist. Nachdem ich den separaten out of the box test mit der dll fertig hatte mußte ich erschrecken feststellen, dass er lief und DevIL gefunden wurde. Den Code zurückkopiert ins Framework lief natürlich nicht. Nun habe ich noch einige andere CMakeskriptstellen angepasst, nichts besonderes, aber dennoch läuft es auf einmal. K.A. was da schief gelaufen ist, nun findet er auch DevIL unter Vista und lädt Texturen bestens ... Mal wieder nen klassischer Fall von Murphys Law und ein zarter Hauch von Magie :roll:

Nun werde ich noch mal nach dem Singeton Problem schauen. Du sagst richtig implementiert, was meinst Du damit genau? Ist ja nen einfaches Pattern, das ich seit Jahren verwende. Denke es ist richtig implementiert läuft ja auch bestens unter Linux oder beziehst Du Dich hier auf die _declspec(dllexport/import) Funktion? Ich habe irgendwo im Netz einige Threads gelesen in denen behautpet wird, dass Singletons nicht über DLL Grenzen hinweg laufen sondern unter Windows pro DLL eine Objektinstanz erzeugen. Das würde nach wie vor mein Problem erklären, da ich aus zwar beliebig das Singleton instanziieren kann, da es aber unterschiedliche Objekte sind ich die gesetzten Werte auch nur im Kontext der DLL abfragen kann ...

[kimmi]

Zu dem Thema habe ich das gefunden:
http://www.gamedev.net/community/forums ... _id=384292
Es funktioniert, da jede Dll jeweils nur einmal in die Exe gemappt wird und das Singleton die Speicher-Position der statischen Variable zurückgibt, die in den Prozess gemappt wurde. Hast du aber dein Singleton per statischer Library mehrfach eingebunden, gilt dieses nicht, da ja das statische Objekt mehrfach hinzugelinkt wurde und dementsprechend auch mehrfach die Variable vorhanden ist. Wir hatte so ein Szenario mal in der ZFXCE und ich habe recht lang gebraucht, diesem auf die Schliche zu kommen.
Allerdings rate ich dringend von zu vielen Singletons ab. Meistens tarnt man hinter einem Singleton nur globale Daten, wie dann doch überall referenziert werden, was für die Wartbarkeit und Verständlichkeit sehr sehr böse ist. Aber bei Logging mache da gern mal eine Ausnahme.

Gruß Kimmi

[Hellhound]

Danke für den Link, ich werde mir das mal genauer anschauen. Nach dem ersten kurzen Überfliegen, sieht's aber genau nach dem aus, was ich so im Hinterkopf hatte ... Ansonsten kann ich mir ja auch mal Eure ZFXCE anschauen ;)

Deine Aussage bzgl. Singletons würde ich so nicht unterschreiben. Gebe zu, dass man nicht überall Singletons reinhauen sollte wo es geht und man sie wohl überlegt einsetzen sollte... Aber grad meine Erfahrung als QM und Software-Architekt aus der JAVA Welt zeigen mir, dass es schon wichtig ist, hier und da auf Singletons für Factories und Manager zurückzugreifen. Grade letzteres wird häufig in der JAVA Welt nicht eingesetzt und man pumpt am Ende den Speicher zu ...

[joggel]

[Etwas Offtopic]
Ich habe gerade auf eurer Projektseite gesehen, dass Ihr OpenSceneGraph verwendet, oder?
Besser gesagt "osgPPU", aber dort steht ja "osgPPU is a library to use with OpenSceneGraph."
Habe mir dann mal etwas OpenSceneGraph angeschaut....
Was genau ist das?

[Alexander Kornrumpf]

Was ein SceneGraph ist weißt du?

[joggel]

Was ein SceneGraph ist weißt du?

Naja, so wie ich das gerade bei Wikipedia lese, ist es eine Struktur zum Speichern von Objekten einer 3D-Szene!
Damit schneller Objekte gezeichnet werden können, geprüft ob diese sichtabr sind, vlt. auch noch für KollisionsTests, usw.

Wenn an es an dem so ist, dann kann ich mir die Frage wahrscheinlich selber beantworten.
OpenScenGraph ist eben eine Bibliothek, die Objekte in einer 3D-Welt verwaltet.
Oder?

[Alexander Kornrumpf]

Naja ich will nichts falsches erzählen aber was ich hier an der Uni so mitbekommen habe, ist OSG sozusagen die "Industrieversion" einer Rendering Engine.

Auf der Homepage von denen steht auch sowas in der Art:

The core scene graph encapsulates the majority of OpenGL functionality including the latest extensions,

[joggel]

Aha,

also eine "Industrieversion" von z.B. Ogre3D.

[Chromanoid]

bei uns an der uni wird das in verbindung mit vr juggler für das CAVE system benutzt (Virtual reality kram)... die programmierung machte einen komfortablen eindruck...

[Alexander Kornrumpf]

Aha,

also eine "Industrieversion" von z.B. Ogre3D.

Genau. Habe auf deren langsamer unübersichtlicher Seite nun aber auch das FAQ gefunden:

It is a 3D graphics library for C++ programmers. A SceneGraph library allows you to represent objects in a scene with a graph data structure which allows you to group related objects that share some properties together so you can specify common properties for the whole group in one place. OpenSceneGraph can then be used to automatically manage things like the level of detail necessary to draw the scene faithfully but without unnecessary detail which slows down the graphics hardware drawing the scene.

[Hellhound]

Hehe, der Thread zeigt mir, dass ich mal die Projekthomepage aufräumen muß :o . Wir sind inzwischen von OSG (Open Scene Graph) nach fast 4 Jahren Entwicklung weg und haben uns entschieden doch lieber alles selbst zu implementieren, da wir mit dem OSG Framework ziemliche Probleme hatten und es einem zu starken Restriktionen auferlegt... Zudem ist OSG zu instabil, ich habe in den 3 Jahren 3 oder 4 Major Umstellungen gemacht, die mich auch zu massiven Anpassungen gezwungen haben. Und die Community war selten hilfreich, da hieß es immer nur, wechlse auf die neuste Version ...

Aber um hier mal die Fragen weg zu nehmen. OSG ist keine Industrie-Version eines Szenengraphen, sondern wirklich OpenSource und mehr Community getrieben, wenn man von Industriegetrieben spricht müsste man eher von OpenSG sprechen... OSG ist ausschließlich OpenGL basiert und nicht wie Ogre eine Cross-Render Engine Platform, zudem liegt der Schwerpunkt ggü. Ogre wirklich auf dem Szenengraphen, wodurch beide schwer vergleichbar sind. Ogre ist an vielen Stellen schon viel weiter als OSG und vieles lässt sich auch nur schwer in OSG umsetzen (z.B. Multipass Shading), das war u.A. einer der Gründe warum wir letztendlich von OSG weg sind und inzwischen alles neu aufsetzen...

Schwerpunkt eines Szenengraphen ist es eine 3DSzene als Baumstruktur abzubilden, wobei die einzelnen Knoten Platzhalter sind die Objekte und Teilobjekte beinhalten können. Jeder Knoten ist mit einem autom. Culling Mechanismus verknüpft, so dass sichergestellt ist, das einzelne Elemente außerhalb der Szene nicht gerendert werden, so können ganze Äste ausgeblendet werden. Innerhalb des Knoten herrscht eine Parent-Child Abhängigkeit, wobei die "Kids" i.d.R. das Verhalten der Eltern übernehmen, was vieles vereinfacht ... Hier mal ne kleine Einführung http://wiki.delphigl.com/index.php/Szenengraph

Aus meiner Erfahrung her sind Szenengraphen heute wichtige wenn nicht das wichtigste Element einer 3D Engine, neben Portalen ect. ...

[Alexander Kornrumpf]

industrie im übertragenen sinne

[eXile]

Wir sind inzwischen von OSG (Open Scene Graph) nach fast 4 Jahren Entwicklung weg und haben uns entschieden doch lieber alles selbst zu implementieren, da wir mit dem OSG Framework ziemliche Probleme hatten und es einem zu starken Restriktionen auferlegt... Zudem ist OSG zu instabil, ich habe in den 3 Jahren 3 oder 4 Major Umstellungen gemacht, die mich auch zu massiven Anpassungen gezwungen haben. Und die Community war selten hilfreich, da hieß es immer nur, wechlse auf die neuste Version ...

Dito. OSG rangiert auf meiner Hass-Liste irgendwo zwischen CORBA und SOAP. Wobei man ja CORBA und SOAP ja kombinieren kann, dann wirds wiederum knifflig ... :x

(Sorry, diesen Post konnte ich einfach nicht lassen :D)