Bereits seit einiger Zeit geistern bei uns im Foren erste Testversionen der neuen DGL-Header, die neben .NET auch Linux und Freepascal unterstützen. Da es in der recht lang angelegten Beta-Phase keine größeren Schwierigkeiten gab, wurden die Header nun offiziell von uns freigeben und können ab sofort von unserer Seite bezogen werden. Wie immer gilt, dass Fehler bitte bei uns gemeldet werden. Gerade auch im Linux-Bereich haben wir momentan nur sehr wenige Tester. Bitte setze Euch mit mir in Kontakt, sofern Ihr die Header nutzt, damit wir ein Bild davon kriegen, ob auch dort alles problemlos funktioniert.

//edit: Kurze Zeit nach der Veröffentlichung gab es ein Meldung für einen Patch, der die Header hoffentlich auf allen Linux-Plattformen lauffähig macht. Wir haben die gepatchte Version unter der gleichen Version veröffentlicht wie die hier angekündigte. Windows-Nutzer müssen keine neue Version ziehen, da sie keine Vorteile davon haben, sollten allerdings zur Kenntnis nehmen, dass Ihre Version noch als 1.8 Beta läuft. Dies ist eine vollwertige 1.9. Als kleine Entschädigung gibt es für die Interessierten noch ein Template für WinForms wer die Header schon einmal für .NET verwenden möchte

DGL-Header 1.9
OpenGL-Template (WinForms)
Änderungen:

1) InitOpenGL braucht nicht immer aufgerufen zu werden. CreateRenderingContext ruft jetzt automatisch InitOpenGL auf, so daß es keinen Fehler mehr gibt, falls man dies vergessen hat.

2) ActivateRenderingContext hat jetzt einen zweiten default Parameter, der standardmäßig auf true steht und angibt, ob alle Funktionen geladen werden sollen. Unter .Net dauert das Laden aller Extensions mehrere Sekunden und daher stellt man ihn dann besser auf false. Die Punkte 3) und 4) betreffen nur diesen Fall.

3) Alle Extensions haben jetzt eine extra Read_ExtensionName Funktion mit der die Extensions einzeln geladen werden können, falls man sie nicht alle beim Start lädt.

4) Es gibt für jede Funktion außer denen, die schon in InitOpenGL geladen werden, einen speziellen Stub, der die Funktion beim ersten Aufruf lädt. Falls man also ActivateRenderingContext mit false benutzt und die Extension nicht einzeln lädt, wird die Funktion beim ersten Aufruf initialisiert. Dies ist der empfohlene Weg unter .Net.

Code:
glCreateRenderingContext(...)
glActivateRenderingContext(...,false)


Der Rest funktioniert automatisch und falls die Funktion vorhanden ist, gibt es auch bei nicht initialisierten Zeigern jetzt keine Exception mehr.

5) Unter .Net gibt es ja keine Zeiger in dem Sinne wie gewohnt und deshalb ändern sich einige Parameter. Die meisten Zeiger wurden in Arrays umgesetzt. So erwartet glVertex3fv jetzt ein Array von 3 oder mehr Single Variablen.
Für kompliziertere Fällen wurden spezielle Wrapper Funktionen eingeführt. So akzeptiert glTexImage2D jetzt direkt ein System.Drawing.Bitmap, einen Stream oder einen String mit einem Dateinamen. In den beiden letzten Fällen können so ohne viel Aufwand bmp,jpg,tif,gif und png Dateien geladen werden.
glReadPixels gibt übrigens auf Wunsch direkt ein Bitmap zurück.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Also die neue Nummerierung (Jahr.Release) verwendet ihr nur bei der DGL-SDK?

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ja. Wir haben uns bei der Nummerierung der Header anfangs ein wenig verlaufen und wollten bisher keinen Bruch machen. Ich denke, dass wir bei der "2.0" dann die Chance nutzen eine sinnvollere Nummerierung im Form von "OpenGL-Version.Release" machen, so dass man auch schnell einmal eine Bugfix hinterher schieben können.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

WOW was habt ihr da denn alles reingeballert
mein VCL Template vergrößert sich um 100kB obwohl meine alte dglOpenGL.pas gar nicht soooooo alt war...wieso müsst ihr auf einmal auf all diese Units zugreifen...ich weiß man sollte als professioneller Programmierer nicht darauf achten aber mich stört es irgendwie.

Muss ich etwa wieder auf die Delphi OpenGL.pas zurückgreifen lol

naja is ja auch nicht sooo wild...

dachte nur wegen dem Internet und alten Modem Usern aber mein DSL 3000 fügen diese 100kB nur 0.3 sek Wartezeit hinzu also nur halb so wild...

Es sind ca 10.000 Zeilen mit Stubs für die OpenGL Funktionen hinzugekommen, die die Extension beim ersten Aufruf automatisch laden. So gibt es keine Fehler mehr in der Hinsicht und das Laden geht insbesondere unter .Net schneller.

Das irritiert mich jetzt. Ich arbeite teilweise mit mehreren RenderContexten die ich hin und her Schalten muss. Das bedeutet ja jetzt, dass jedesmal OpenGL zurückgesetzt wird und das kostet sicherlich Zeit. Gibt es einen Parameter mit dem man das unterdrücken kann?


Heißt das jetzt, dass der Header nicht mehr OpenGL konform ist? Alte Programme Funktionieren wohl mit dem neuen Header auch nicht mehr oder?

Also wenn letzteres gilt, muss ich mal Fragen, obs auch ne Headerversion ohne .Net gibt, die einfach nur die neuen Funktionen enthält ohne am Headerkonzept was umzuändern...

Bin gerade ziehmlich irritiert über die "Features".

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

zu 1) Das passiert nur, wenn die Funktionen noch nicht geladen wurden.
zu 5) Das betrifft nur die .Net Version. Da gibt's zwar Zeiger aber eben nur sehr ungünstig. Das direkte Gegenstück sind Arrays.

siehe auch:


Es bleibt also ansonsten alles beim alten.

Das automatisch Laden hat sich halt wegen .Net angeboten und weil es dauernd Fehler gab, wenn jemand es vergessen hat. Außerdem kann man Extensions auch geziehlt dem Namen nach Laden, was auch mal gewünscht wurde wie bei den Headern von Delphi3D.Net.
Der Header ist (sofern es keine Fehler mehr gibt) vollständig kompatibel zu der alten Version. Die .Net Sache ist bitter notwendig um auch unter .Net eine Alternative zu Managed DirectX anbieten zu können. Dort braucht man nämlich keinen Header, sondern nur "Referenz hinzufügen...". Es gibt keinen .Net 1.1, d.h. auch Delphi 2005 Header ohne Zusatz DLL's, außer dglopengl.pas und daher ist das die einzige sinnvolle Möglichkeit OpenGL auf dieser zukunftsweisenden Plattform zu betreiben.

Ok...das beruhigt. Solange die Änderunegn am Format nur .Net treffen.

Auf lange sicht würde das aber heißen, dass die openGL Spezifikation nicht 1zu1 auf zukünftigen Maschienen (mit .Net) umgesetzt werden kann, oder? Wenn dem so ist, müsste OpenGL.org quasi die Spezifikation irgendwann an .Net anpassen. Weil in OGL ja Pointer durchaus wichtig sind...

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

Naja... Irgendwann muss alles mit der Zeit gehen. Jeder, der sich degegen stellt wird früher oder später mit dem Strom mitgerissen werden oder untergehen.
Ich hoffe aber mal stark, dass dann eine neue Spezifikation in Form von überladenen Methoden daherkommt, dann müsste man alte Quellcodes nicht anpassen...

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Der Header entspricht auch unter .Net den Spezifikationen. Die Zeiger sind ja meistens Zeiger auf Arrays. glVertex3fv, glTexImage2D usw... Zeiger auf Arrays sind unter .Net bereits die ganz normalen Array Typen. Da gibt's keinen Grund untypisierte Zeiger einzubauen. int[], float[], ref int usw... sind unter .Net der direkte Ersatz für PIntegerArray,PSingleArray, PInteger usw...

Ja aber wenn unter .Net für glTexImage2D keine Zeiger mehr angegeben werden, sondern direkt die Bilder oder der Dateiname, dann entspricht das doch nicht mehr den Spezifikationen.

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Die alten Funktionen gibt es ja auch noch weiterhin. Außerdem kannst du auch ein Array angeben.



PGLVoid ist unter .Net ein IntPtr, also ein belieber Zeiger, der auf sichere Art und Weise von allen Objekten geholt werden kann.