Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab in den letzten 2 Tagen eine c lib geschrieben, welche die spec und tm files von opengl.org parsen kann. Das hab ich getan, weil ich aus den opengl specs mir c++ code generiere.
Als das ganze funktionierte hab ich fest gestellt, dass OpenGL mit allen Extensions, ARB und Core 1.0-4.3 ~6000 funktionen und 300 datentypen enthält. Das ist echt übel, da ich für mein generierten Code die Extensions und ARB nicht brauche filtert er alle Core funktionen raus. Da waren es nur noch ~1000 Funktionen und die Anzahl der seit 3.1 als deprecated gemarkten Funktionen, im Core, sind einige hundert funktionen. Ich hab noch nicht geguckt, wieviel genau übrig bleibt, wenn man auf ein 3.1 und aufwärts Context setzten würde aber im Vergleich zu den ~1k Funktionen, die man bei abwärtskompatibilität berücksichtigen muss und dann braucht man noch ARB Funktionen, wen man Shader und/oder Vertex Buffer Objects in 1.5 bis 2.0 verwenden will.
Also an sich sind das wesentlich mehr Funktionen als ich vermutet habe und dies hat seine Auswirkungen. So hatte ich bei einigen Extensions und ARB Funktionen Probleme mit dem gl und glew headern zu kompilieren, da diese unterschiedliche Definitionen der Funktionen hatten. Da wurde mal aus einem "const float*" ein "const float[16]", was für den vc++ compiler ein unterschied macht und meckert. Die gl.spec und gl.tm ( http://www.opengl.org/registry/#specfiles ) definieren die Typen sehr genau und einige extension libs scheinen in der Handarbeit wohl Fehler gemacht zu haben. Ich finde es beachtlich wie klein die API seit 3.1 geworden ist und nicht an flexibilität verloren hat. Da hat man ja nicht gezaubert, sondern ledeglich die Funktionalität in Shader ausgelagert und dies macht auch das ganze Konzept viel schöner. Weniger GL Funktionen führt auch zu weniger Calls und somit mehr performance und weniger Fehlermöglichkeiten. Die Shader werden in nativen byte code gewandelt, damit die gpu den kram wesentlich schneller verarbeiten kann und da gibt es gute Werkzeuge, um speziell diesen Bereich unter die Lupe zu nehmen, was wesentlich einfacher ist als im Programmcode nach falschen oder langsamen GL Calls zu profilen.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Mitglieder in diesem Forum: 0 Mitglieder und 12 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.