Interessante Wortwahl.

Der Header ist schon so aufgebaut, dass sowohl Konstanten als auch Methodendefinitionen und Ladefunktionen im Code sauber nach einzelnen Erweiterungen getrennt sind. Alleine schon aus Gründen der Übersicht. Entsprechend wäre so eine Lösung mit den Conditional Defines sogar halbwegs einfach nachgerüstet. Wenn man so etwas richtig macht, dann dürften auch nur die Konstanten verfügbar sein von den Erweiterungen die aktiv sind. Allerdings liegt das Problem dabei eher im Versteckten. Mal ein "kleines" Beispiel um das zu verdeutlichen.

Wir schreiben eine aktuelle Anwenung. Mit Shadern, VBOs und mehreren BGR(A) Texturen. Nicht ganz ungewöhnlich. Texturen sind OpenGL 1.1 definiert. BGR(A) in 1.2. Multitexturing in 1.3. VBOs in 1.5. Und glSlang in 2.0.
- Von 1.1 bräuchten wir nur die Initialisierung und einige State. Eine Hand voll Methoden (+Vertex Arrays (Bestandteil von VBO)).
- Von 1.2 lediglich die Konstanten. Methoden werden gar nicht genützt
- Von 1.3 brauchen wir nur die Konstanten und die Möglich eine Textur zu aktivieren. Eine einzige Methode.
- Von 1.5 bräuchten wir sogar fast 25% der dort enthaltenen Methoden.
- von 2.0 nur die Shader und das wären auch nur 8-10 Methoden.

Insgesammt bestehen diese Kernversionen aber aus ziemlich genau 530 Methoden. Und je nachdem wie Flexibel man sein Programm schreiben möchte müsste man sogar noch glSlang als Erweiterung unterstützen etc. Dadurch kommen dann noch mal die gleichen Methoden mit einem anderem Namen hinzu. Viele der eher exotischen Erweiterungen bestehen meistens auch nur aus ein paar Methoden. Aber den Großteil den würde man meiner Meinung nach mit Conditional Defines trotzdem noch mit rumschleppen. Aber zu mindest hätte man das Gefühl was gesparrt zu haben.

Ich bin auf gar keinen Fall gegen irgendwelche Ideen. Ganz im Gegenteil. Allerdings denke ich, dass Conditional Defines in diesem Fall eher nur einen "emotionalen" Nutzen anstelle eines Tatsächlichen haben werden. Zu mal in der Testversion es auch Möglich ist das Laden der Methoden zu deaktivieren und einzelne Erweiterungen auf ein Mal komplett zu Laden. Also zum Beispiel durch Read_GL_ARB_vertex_buffer_object. Und das brauchte man auch nur dann machen, wenn OpenGL 1.5 nicht unterstützt wird. Mit Conditional Defines würde ja eigentlich beides dann geladen werden müssen. Sozusagen ist es aktuell sogar noch sparsamer.

Etwas was als Argument definitiv für Conditional Defines sprechen würde wäre die geringfügig verbesserte Übersicht. Wenn man Erweiterungen deaktiviert, dann wären, bei der Codevervollständigung, auch die Methoden/Konstanten weg. Das würde dem Ganzen zu mindest ein bisschen Fülle nehmen. Allerdings bin ich mir nicht sicher ob das so häufig genutzt wird. Denn wenn jemand weiß was er deaktivieren kann, dann muss er eher nicht mehr suchen und wird nicht von anderen Methodendefinitionen gestört.

Ich halte es für Sinnvoll, wenn nicht die Versionen an bzw. abgeschalten werden kann, sondern noch viel tiefer gehend die einzelnen Module an und abschaltbar zu machen. Ich halte z.B. die Möglichkeit den ganzen Immediate Mode wegschalten zu können oder z.B. alles mit Texturen, FBO, VBO, PBO, GLSL an bzw. abschalten zu können. Also neben den Versionen noch diese Flags an und aus zu schalten. Dann werden erst der Code raus geworfen, welcher z.B. zu OpenGL 3.0 gehört und dann geht er im restlichen Code weiter und wirft Module raus, die nicht gebraucht werden(z.B. Immediate).
Dann habe ich mein GLSL, VBO, FBO, Texturkram und Core noch drin. Dies erlaubt auch den Header anders zu gestalten. Im Vorraussicht auf OGL3.x werden z.B. die Immediate Mode Funktionen nicht gebraucht, auch einiges andere und das kann man dann per define recht einfach weg schalten.
Jeder freut sich über kürzere Compiler zeiten und ein schnellerem Programm Startup, sowie weniger Speicherverbrauch.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also ich muss gestehen, dass ich mir deinen Posting gerade mehrmals habe durchlesen müssen um es halbwegs zu verstehen. Und selbst jetzt bin ich mir nicht sicher ob ich es wirklich verstanden habe. Entsprechend kann es sein, dass ich dich jetzt missinterpretiere. Sollte das der Fall sein bitte ich dies, schon mal vorab, zu entschuldigen.

Zum Thema OpenGL 3.X. Es steht völlig außer Frage, dass es das einzig Sinnvolle wäre, wenn man nur noch Funktionen zur Verfügung hat, die nicht als veraltet markiert wurden. Das betrifft ja primär aber nur echte 3.0 Renderkontexe. Und was die Definition der veralteten Methoden angeht ist die Doku ja etwas schwammig (sehe zu mindest ich so). Aber das war nicht das eigentliche Thema und dazu muss der Header später sowieso noch mal angepasst werden. Denn dann bräuchte man vermutlich auch noch eine andere Initialisierung des RCs.

Was die Unterteilung der OpenGL Funktionalitäten in einzelne Teilbereiche angeht. Da muss ich gestehen habe ich entweder deine Ausführungen nicht verstanden oder mir bleibt der Sinn dahinter verschlossen. Allerdings werde ich eine solche Unterteilungen in Themenbereiche nicht durchführen. Ungeachtet davon von wievielen Personen den Header gepflegt wird, ist er ein Stück Quellcode der Community. Als Mitglied der Community steht es dir natürlich frei ihn zu überarbeiten und dann in der passen Sparte vorzustellen.

Ich kann Lossy da verstehen. Die Header Pflege ist ziemlich viel Arbeit und auch eine gewisse Verantwortung.
Nebenbei wurde der Header ja schon bei Demo-Projekten eingesetzt. Dort hat dann der Programmierer den Header fürd as projekt auf das zusammengekürzt was er brauchte.
In normalen Projekten ist das denk ich nicht notwendig.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich gebe ja auch nur Kritik und Ideen, da ich ja den dglOpenGL.pas garnicht nutze(c++ nutzer).
Allerdings hat es mich früher immer gestört, wenn ich mit fpc versucht hab was kleineres zu programmieren(z.B.64k Demo).
Denn das ging nicht weil das compilieren von dglOpenGL.pas ja schon die exe auf über 100kb brachte.
Im Prinzip hab ich dann in ziemlich aufwändiger Arbeit mir die einzelnen Konstanten und Prozeduren raus kopiert und selber geladen.
Ein Problem dabei war dann z.B. der ARB support, welche funktion läuft auf welchen OpenGL und welchen Chipsatz.
Viele Notebooks der letzten Generation, mit z.B. einen intel chipsatz können zwar 2.1 aber nur über die ARB's(was zum glück auf deren Seite stand).
Wobei ich dann bei der Übersicht wäre, die mich viel mehr stört. Ich mag diese Monolithische(alles in einer datei) Variante mal garnicht, da man da einfach kaum noch durchsieht und mehr Zeit mit dem suchen als mit dem fixen verbringt.
Als ich mit Linux angefangen hatte und der dglOpenGL Header noch nicht kompatibel war, hab ich auch viel zeit damit verschwendet, durch den Urwald an verschachtelung und funktionskapselung zu finden um dann die entsprechenden Fehler im Header zu finden, damit es unter Linux läuft.
Gleiches Problem hatte ich dann wieder unter Linux aber diesmal mit dem OpenGL 2.1 support auf ATI, wo der Header noch nicht den Specs von ATI entsprechend angepasst war und dinge wie GLSL,VBO und FBO ned liefen.
Man sollte vieleicht mal über eine Umstrukturierung überlegen.
Dabei den Code Segmentieren(ist er ja schon) und in einzelne includes packen, dann wird der dglOpenGL.pas übersichtlicher und hat auch schon die schönen Defines(jedes include halt). Man hat dann übrigens den Vorteil, dass der Header leichter zu pflegen ist, da mehrere Personen daran arbeiten können und die änderungen in den Includes die anderen nicht beeinflussen. Der Header liegt ja eh im SDK oder als Archive vor, daher sollten die aufsplittung in Datein kein handling Problem darstellen.

OpenGL 3.x Also bei NV findet man auf der Seite schon die Specs verlinkt, was depricated ist was nicht und so weiter.
http://developer.nvidia.com/object/opengl_3_driver.html

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich versuche nur deine Anregungen zu verstehen. Denn wie kann ich etwas beurteilen, wenn ich es nicht ganz verstehe!

Von Includes halte ich persönlich absolut nichts, denn dadurch zerreißt man Code der eigentlich eins ist. Optionen etc gehören dort rein. Keine Frage. Aber Code nicht. Denn für solche Sachen bräuchtest du 2 includes. Eines im Interface und eines im Implementation Teil. Klar der eigentlich Code ist kleiner aber für mich sinkt dadurch die Übersicht enorm. Denn in einem Include fehlen zum Beispiel die Typen die oben drüber definiert sind. Und das erschwert das Handling viel mehr als eine 700 kb Große Datei. Zu mal auch da wieder das Problem dazu kommt, was ich oben als Beispiel hatte. Wirklich viel kleiner wirds trotzdem nicht.

Was Linux angeht. Tja was soll ich sagen. Du warst der Erste der das tatsächlich dort benutzt hat. Und der entsprechendes Feedback gegeben hat. Das ist mit den OpenGL 3.0 Änderungen jetzt genau das Gleiche. Kann ich nicht testen. Muss ich hoffen, dass es geht. Aber da noch mal danke für den gesammten Input.

Was die Größe angeht hättest du mit der aktuellen Version dann keine Probleme mehr. Denn die Variablen sind nach wie vor existent und du könntest Funktionen mit einem einzelnen Funktionsaufruf laden. Der Smartlinker tut den Rest.

PS: Den Link werde ich mir bei Gelegenheit mal anschauen. Danke.