Die Tage hat mich Dominique Louis über momentane OpenGL-Headersituation unterhalten. Z. Zt. wird der JEDI-SDL Header als quasi offiziell gesehen, kann aber nur OpenGL 1.3; ist jedoch Crossplattform und -compiler. Er hat daher angefragt was ich so zu der Situation meinte, und ich habe ihm gesagt dass es evtl. möglich wäre dass wir unseren Header JEDI-Konform machen. Im Einzelnen würde dass bedeuten dass er Crossplattform und -compiler sein müsste, letzteres ist ja bereits so (zumindest FPC klappt neben Delphi).

Ich wollte daher mal die Leute aus dem Portteam hier fragen ob ihr bereit wäret den Header JEDI-Konform zu machen. Das wäre zwar etwas Mehrarbeit, hätte aber dann den Vorteil dass unser Header offiziell ist (und im Endeffekt sogar der EINZIGE Pascal-OpenGL-Header, darum gings Dominique und mir nämlich) und es evtl. sogar mal zum offiziellen Delphi-GL-Header bringt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also ich denke mal, dass das ein Stück weiter in Richtung Weltherrschaft ist und von daher spricht da von meiner Seite aus nichts dagegen. Allerdings stellt sich mir die Frage. Was ist eigentlich JEDI Konform? Was müsste denn alles gemacht werden?

Achja. Was mir gerade noch einfällt. Im Zuge einer Umarbeitung wäre ich auch dafür, dass die Methode ReadImplementationProperties aufgelöst wird und mit in die Methode ReadExtensions wandert. Die sind eh direkt von einandere abhängig. Und müssen eh immer beide aufgerufen werden.

Evtl sollten wir dann auch die Quellcodeformatierung an einigen Stellen überarbeiten. Teilweise wurde gar nicht eingerückt, an anderen Stellen nur ein Zeichen und an wieder anderen 2 zeichen. Ich finde das sieht nicht so gut aus.

Da Dominique quasi der Kopf der JEDIs ist, wird er mir das mitteilen. Ich hab ihm gesagt dass ich erstmal das Portteam frage ob überhaupt Interesse besteht. Aber wie bereits gesagt muss der Header dann mit den verschiedenen Pascalcompilern funzen (Delphi, Kylix, FPC, evtl. noch Gnu Pascal, Virtual Pascal und TMT Pascal) und auch Cross-Plattform sein (Windows, Linux, evtl. sogar MacOS, dass kann von uns aber wohl keiner testen). Ich persönlich nutze nur Windows, könnte also nur dort testen (sprich : die für Windows erhältlichen Compiler, wobei TMT Pascal aber AFAIK nicht kostenlos ist).


Wenn wir schon dabei sind den Header "umzustellen", können wir dann ja auch solche Dinge einbringen. Müsste man halt nur sehen wie wir das mit der Crossplattform-Sache im Header realisieren. Evtl. könnte man dann die WGL bzw. GLX-Sachen (gibt dann sicherlich noch sowas ähnliches für Mac) dann in externe Dateien auslagern.


Das sollte gemacht werden. Im Netz gibts zwar so einen Quellcodeformatierer, aber den habe ich bereits mehrere Male mit unserem Header nutzen wollen, und jedesmal hat sich das Ding aufgehangen bzw. mir nen Fehler gemeldet. Evtl. war der Header zu groß, aber zur Not kann man den auch von Hand formatieren.


Bleibt jetzt halt noch die Frage nach den alternativen Betriebssystemen. Linuxport hatten wir dank Delphic ja bereits, evtl. will der wieder daran arbeiten. MacOS ist dann so ne Sache, aber evtl. wird das auch nicht benötigt (gibt ja inzwischen mit Darwin Pascal auch für den Mac).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Habe gerade mal mit DelForExp versucht den Header zu formatieren und damit geht's dann auch. Damit kann man auch anhand der mehr oder weniger offiziellen Vorgaben formatieren.

Danke für den Link. Hatte es damals (k.A. wann) mit der Stand-Alone-Version versucht, und die hat sich am Header erhangen. Mit der in die IDE integrierten Version gehts, allerdings gefällt mir die Formatierung da nicht so sonderlich (Borland-Einstellung).

Werde Dominique aber wissen lassen dass Interesse besteht, und dann mit ihm über die Details reden und euch natürlich auf dem Laufenden halten.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wäre auf jeden Fall sicherlich keine falsche Sache und alles andere als schädlich auch für die "betroffenden" Nutzer. Die aktuellen Header sind per FPC nicht kompatibel. Ich habe einige Stunden versucht sie entsprechend anzupassen. Kompilieren ließen sie sich durchaus, allerdings gab es beim Init, dann stets eine execption (auch wenn die richtige .so-datei scheinbar erfolgreich geladen wurden). Das Mitglied Beos (??) hatte es IMAO schon einmal hinbekommen die Header FPC kompatibel zu machen, als ich ihn anschrieb, entsprechende Änderungen auch für die offiziellen DGL-Header zu machen, brach das große Schweigen aus.

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

Ich habe noch ein paar Extensions zu dem Header hinzugefügt. Also die aus diesem Thread. Und zwar habe ich mich auf die ARB, EXT und NV beschränkt. In dem Archiv ist allerdings nur der Header. Die HTML habe ich gerade nicht.

Ich werde mich die Tage hier mal um die Unterstützung für verschiedene Compiler kümmern. Momentan schreibe ich am FP-Template (scheint soweit zu funzen, ohne was am Header ändern zu müssen) und GNU-Pascal ist auch schon installiert (nutze für beide die DEV-Pascal IDE), mal sehen ob GP den Header auch so einfach schluckt.

Kennt jemand von euch noch andere Pascal-Compiler für Win32 die vom Header unterstützt werden sollten? Wenn ja, dann wären Links dazu ganz nett.

Edit : Mit Freepascal scheints einwandfrei zu laufen (Win32), und eben habe ich auch noch Support für Virtual Pascal implementiert und eines der dort mitgelieferten Beispiele auch erfolgreich mit unserem Header kompiliert. An GNU-Pascal habe ich mir allerdings (allein schon deshalb weil Dev-Pascal keine sonderlich bug-freie IDE ist) stundenlang die Zähne ausgebissen und den Header dort nicht kompatibel bekommen (die Doku zu GNU Pascal ist auch irgendwie total inkomplett), evtl. hat da einer von euch schon Erfahrung mit und kann mir etwas auf die Sprünge helfen. Ansonsten gibts ja noch TMT-Pascal, aber momentan sind die Downloads auf deren Seite nicht verfügbar.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hab jetzt endlich ein halbwegs brauchbares Cross-Compiler Template für die dglOpenGL.pas zusammengebastelt. Momentan läuft es mit FreePascal und VirtualPascal, aber in Sachen GNU Pascal brauche ich unbedingt etwas Hilfe : Der einzige Editor den ich dafür gefunden habe (Win32) ist Dev-Pascal, und da lassen sich nichtmal die Beispiele kompilieren, und da bei der dglOpenGL.pas die sysutils genutzt wird, und sich diese nicht erstellen lässt, komme ich erst gar nicht dazu den Header GNU-Pascal kompatibel zu machen. Wenn sich da jemand auskennt, bitte melden. In Sachen TMT-Pascal siehts auch schlecht aus, denn deren Win32-Pascalcompiler gibts gar nicht zum Download, sondern nur gegen Bares.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

http://www.pgd.netstarweb.com/viewtopic.php?t=1798
Für den Fall, dass das bisher niemand gesehen hat. Hat sich bisher jemand darüber beschwert, dass die Header Exe-Dateien aufblähen?

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

Normalerweise werden nicht benutzte Funktionen,Variablen,String Konstanten usw... doch eigentlich gar nicht mit in die EXE Datei übernommen. Der FP Compiler soll doch angeblich besser sein als Delphi. Daher ist das verwunderlich.

Naja. Wir laden zu begin ja alle Extensions. Somit werden alle Methoden auch ein mal benutzt. Der Compiler kann das dann aber nicht mehr ausfiltern. Und im Vergleich zu dem Umfang mit der OpenGL haben wir ja doch so 1-2 Funktionen mehr. Also ausschließen würde ich das nicht aber ich wüsste keinen anderen Weg wie man es gestalten sollte ohne (wie Tom Nuydens Header) alle Extension einzeln ladbar zu gestalten.

Ja das stimmt natürlich. So eine globale Optimierung wäre auch ein wenig zuviel verlangt. Das mit dem einzeln laden wäre auch wegen der .Net Version eine sinnvolle Sache. Man braucht ja sowieso die ganzen exotischen Extensions gar nicht, auch wenn es wichtig ist, sie der Vollständigkeit halber dabei zu haben. Man muß nur sehen, wie man das sinnvoll einrichtet, dass nicht gleich wieder die Hälfte der Leute Probleme damit bekommen. Der Aufruf von InitOpenGL scheint ja schon sehr häufig vergessen zu werden.
Die alte Funktion ActivateRenderingContext muß also auf jeden Fall beibehalten werden. Ein optionaler Parameter für das Laden aller Extensions wird aber vermutlich nicht ausreichen, dass Delphi dies erkennt und die Sachen rausläßt, wenn dieser Parameter immer auf false ist. Dann darf man diese Funktion gar nicht mehr benutzen und muß auch das wglMakeCurrent selber machen oder eine neue Funktion dafür verwenden, wenn man nicht alle Extensions laden will. Wenn jetzt Änderungen vorgenommen werden, dann bitte an der vorläufigen .Net Version, weil die auch auf der letzten normalen veröffentlichten Version basiert.

Also gerade im .NET-Bereich gebe ich mich mal sehr laienhaft... aber was Spräche gegen den Einsatz von Compilterdirektiven in denen man einfach eine Subversion (5 für OpenGL 1.5) setzt und dann entsprechende Extensions mit einbindet. Die setzen wir als Standard immer auf den neusten Wert, so dass sich im Prinzip nichts zu dem jetzigen Stand ändern. Wenn dann jemand das ganze zu aufgebläht findet, kann er in seinem Programm als Ziel eine andere version angeben und entsprechend neuere Extensions werden dann nicht geladen. Ich denke nicht, dass ein einzelnes Nachladen wirklich erstrebenswert wäre. Ich denke wenn man sich ansieht wieviele Probs es mit dem Init gibt, sehe ich schon die ersten, die sich wundern, warum die Extensions nicht mehr laufen.

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