Die aktuelle Version und das dazugehörige Changelog findet sich immer in diesem git-Repository
Dort findet sich auch eine detaillierte Readme (als Markdown) mit Versionsinformationen.

Letzte Änderung am 2015-09-03 :


(wiki Eintrag)

Unterstützt werden Delphi, Free Pascal und diverse Plattformen (Windows, Linux, Mac OS X, etc.)

Der Header wurde so ausgelegt, das ein Umstieg von z.B. Mike Lischkes OpenGL12.pas einfach fallen sollte, denn er enthält sowohl die dort verwendeten Datentypen (z.b. TGLFloat), also auch selbige ohne vorangestelltes "T".Darüberhinaus beherbergt diese Unit auch die an Mike Lischkes Unit angelehnten Helferfunktionen wie z.B. CreateRenderContext und ActivateRendercontext (ersteres mit leicht veränderter Parameteranzahl).

Und auch euer Feedback wurde erhöhrt, und die Probleme mit der bisherigen Unit sollten allesamt behoben sein, auch fehlende Extensions bzw. Konstanten wurden hinzugefügt.

Viel Spaß also mit der neuen Unit, die ihr jetzt getrost als Ersatz für die Unit von ML nutzen könnt (hab meinen Basecode auch schon komplett umgestellt).Aber vergesst bitte nicht, das wir immernoch auf euer Feedback angewiesen sind, weshalb ihr etwaige Probleme oder fehlende Dinge hier posten solltet.

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

Also mir gehen 2 Typen ab:

TMatrix4d und TVector4i. Fragt mich bitte nicht, ob der Fehler bei mir liegt. Aber direkt nach der Umstellung hat mich mein Compi damit vollgemault.

Des weiteren fehlt die Funktion LoadOpenGL

Die heissen in unserer Unit momentan noch anders.Wird aber im nächsten Release gefixt.


Die fehlt nicht.Das heisst in unserer Unit InitOpenGL, und mittels glReadExtensions lädst du nach dem Initialisieren des Renderkontextes die Extensions.

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

Kompliment an alle Beteiligten! Die neue dglOpenGL ist sehr umfangreich und dabei auch noch übersichtlich. Sämtliche Extensions sind mit Kommentaren im Code abgetrennt - da steckt viel Arbeit drin, wie ich auch aus eigener Erfahrung beurteilen kann.

Das Kompilieren von mit Mcad erstellten Ogl Projekten funktioniert mit Hilfe einer kleinen Hilfsunit einwandfrei, allerdings ist folgende Glu- Funktion nicht implementiert:



die gibt es in der mit Windows gelieferten glu32.dll zwar auch nicht, alternative glu Versionen (ich glaube ab 1.3, bin mir aber nicht sicher), stellen diese aber sehr wohl zur Verfügung (z.B. MesaGLU), obwohl es bei Verwendung von nicht in glu32.dll implementierten Funktionen (zumindest unter Windows) ohnehin eine gute Idee ist, erst mal festzustellen, ob diese überhaupt funktionieren.

Der Source von dglOpenGL ist schön und übersichtlich formatiert, allerdings schaut es so aus, als ob zwei unterschiedliche Formatierungsarten (mit den Einrückungen) zur Anwendung gekommen wären - das Tüpfelchen auf dem i wäre noch, wenn das vereinheitlicht werden könnte.

Was mich bereits bei Lischkes OpenGL12.pas ein wenig gestört hat, sind die vielen ifdefs um Delphi und Kylix gleichermassen zu unterstützen. Während das Unterfangen zwar höchst löblich ist, funktionieren die ganzen Supportroutinen ja ohnehin nur unter Windows, weswegen man die ganzen OpenGL Einsprungpunkte direkt als stdcall definieren könnte.
Die ganzen stdcalls dann bei einer eventuellen Linuxversion (mit eigenen Supportroutinen!) dann durch cdecl zu ersetzen, wäre dank "Suchen und Ersetzen" dann eine Sache von Sekunden - und der Code würde noch etwas übersichtlicher werden.
Was man sich evtl. dann noch überlegen könnte, wäre eine einheitliche Schnittstelle zu Win32 und Linux Systemen, aber das ist, glaube ich, noch ein wenig Zukunftsmusik.

Ansonsten finde ich wirklich nichts mehr zu meckern (und das Angeführte sind ja auch nur Kleinigkeiten) - ich denke hier wurde Delphi OpenGL Programmierern ein großer Dienst erwiesen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Erstmal danke für das positive Feedback, sowas sieht man gerne , und es freut mich das der neue Header auch bei dir ohne größere Probleme funzt.

@ gluBuild3DMipmaps :
Danke für den Hinweis, die Funktion war mir bisher sogar völlig unbekannt.Wird aber auf jeden Fall beim nächsten Headerupdate implementiert.

@ Formatierung & ifdefs :
Wird zur Kenntniss genommen, und im nächsten Release wird da was getan.Ursprünglich sollte der Header auch für Linux nutzbar sein, weshalb da die ganzen ifdefs drin.Allerdings gings uns zuerst mal um eine frühe Veröffentlichung, da es nicht unwahrscheinlich gewesen wäre wenn es GL1.5 bereits in die Catalyst 3.7-Treibern geschafft hätte (dem war leider nicht so).


P.S. : Evtl. für alle NVida-Anhänger ist folgender Thread interessant, denn anscheinend haben NVidia ihrem "wir-cheaten bis zum Umfallen"-Treiber (ich kanns mir leider ned verkneifen...) bereits (zumindest teilweise) OpenGL1.5-Funktionalität drin.

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

Also ich habe ein Problemchen mit dem Header...
Beim Compilieren meldet er mir folgende Fehler:

Undefinierter Bezeichner: 'PPointer' (bei TGLUTessCombineProc)
Undefinierter Bezeichner: 'RaiseLastOSError'

Ich benutze Delphi 5

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

Zu PPointer : Wie der Name vermuten lässt, ist PPointer ein Pointer auf einen Pointer.In Delphi 7 ist dieser Datentyp in der Systems.pas definiert,in älteren Versionen anscheinend nicht.Öffene einfach die dglOpenGL.pas und füge bei den vorhandenen Typendeklaratioenen einfach folgendes ein :


Zu RaiseLastOSError : Komisch das es hier Probleme gibt,denn D5 sollte diese Funktion kennen.Such mal danach in der Hilfe und guck mal (wenns vorhanden ist) in welcher Unit dieses Funktion abgelegt ist und binde diese mal in die dglOpenGL.pas über uses ein.

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

Unter Delphi 5 heißt der noch RaiseLastWin32Error - erst ab Delphi 6 gabs dann ja Parallelversionen von Delphi und Kylix und dann hat man halt auch die Funktion "betriebssystemunabhängig" gemacht.
RaiseLastWin32Error funktioniert allerdings auch noch in Delphi 6 und 7, läuft dort aber als "veraltete" Funktion - ich denke aber für dglOpenGL ist es sauberer RaiseLastOSError beizubehalten und evtl. einen Kommentar für ältere Delphiversionen (5 und älter) im Header einzufügen, die Prozedurnamen auszutauschen.
Den PPointer könnte man aber auf jeden Fall hinzufügen, folgende Datentypen könnte man noch an die OpenGL Nomenklatur anpassen, welche die Elementgröße (b, f, d u.s.w.) als letztes angibt:



Eventuell wäre es auch zu überlegen, für diese Datentypen, sowie für die GLU-Datentypen ebenfalls "T"-lose Versionen anzulegen. Irgendwie hat Lischke mit seinem "T" da mehr Verwirrung gestiftet, als schöneren Code erzeugt

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

@ RaiseLastWin32Error :
Danke für den Hinweis mit RaiseLastWin32Error (wusste doch das da noch sowas war),ich werd das dann mal in den Kommentaren des Headers anmerken.

@ Datentypen :
Wurde auch zur Kenntnis genommen und wird auch im nächsten Headerupdate berücksichtig.

@Mike Lischkes "T" :
Sehe ich genauso.Borland sagt zwar man solle seine eigenen Typen mit einem "T" beginnen,allerdings finde ich sowas bei ner Headerkonvertierung nur suboptimal.glFloat wäre mir auch lieber als TGLFloat und würde dann ja letztendlich auch dem Original entsprechen.Allerdings würde dies eine Migration von MLs Header auf unseren verkomplizieren.

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

Hab grade die alte Version durch die aktualisierte ersetzt.Folgende Neuerungen sind jetzt enthalten :

# PPointer deklariert (Kompatibilitätmit Delphi <7)
# Eigene Prozedur RaiseLastOSError+Kommentat (Kompatibilität mit Delphi <7)
# Die von Mars vorgeschlagenen Datentypen mit GL-Syntax eingefügt

Da das alles keine großen Änderungen waren,hab ich die neue Unit nur mit meinem aktuellen Projekt getestet und dort machte sie keine Probleme.Falls es dennoch irgendwo zu Problemen kommen sollte,dann bitte hier im Thread melden.

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

Hieß es nicht, am 15 kommt der offizielle 1.5 Header??. Is der jetzt da oder kommt der noch???

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

Das ist der offizielle Header.Es hiess nur das Phob am 15.Oktober das offizielle SDK rausbringt,dies aber zeitlich wohl nicht schafft.

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

Ich bin auf 1,5 Bugs in dem Header gestossen:

0,5: Zeile 8225 -> 2 Zuweisungen stehen in einer Zeile. Eigentlich kein bug, jedoch "unschön". Stört aber nicht. Hab's nur der Vollständigkeit halber erwähnt.

Der andere iss wirklich ein Bug:
Zeile 8263 -> Auch hier sind mehrere Zuweisungs-Befehle in einer Zeile. Wäre ja nur halb so schlimm, wenn am Anfang der Zeile nicht ein //-Kommentar wäre. Somit werden die nachfolgendne Befehle einfach auskommentiert. Betroffen sind die Funktionen von ARB_Vertex_Shader und ARB_Occlusion_Query (glGetActiveAttribARB, glGetAttribLocationARB, glBindAttribLocationARB, glGetVertexAttribPointervARB, glGenQueriesARB und glDeleteQueriesARB).

Ich schätz' mal, dass es sich um die 1.5 Funktionen handelt und diese noch nicht getestet werden konnten. (Das Auskommentieren könnte ja dann auch absicht sein; keine Ahnung). Wollte es ebenfalls nur mal mitteilen.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Sicher das du den selben Header hast wie er hier angeboten wird?Hab grad nochmal nachgesehen, und bei mir sind die angesprochenen Zeilen und angeblich auskommentierten Funktionen allesamt da...sicher das du den Header hier aus dem Thread hast und nicht aus der DL-Sektion?

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

Eigentlich ist bei der Version aus der DL-Sektion auch alles drinnen - obwohl es dennoch Sinn machen würde, beide Versionen abzugleichen.

Kann es sein, dass du evtl. eine ältere Delphiversion verwendest ? Meines Wissens hatte Delphi (ich glaube bis Version 6 oder so) Probleme mit "Linux" Zeilenumbrüchen (also CR anstelle von CRLF).
Hab da auch schon meine Gaudi gehabt, als ich einen C++ Source nach Delphi konvertierte und dann lauter Fehlermeldungen a'la Zeile zu lang (obwohl in der betreffenden Zeile gar nichts stand) bekam, oder (noch lustiger) das Programm beim Tracen völlig falsche Zeilen anzeigte und die diversen Meldungen den Ort eines Fehlers bestenfalls ungefähr erahnen ließen.

Abhilfe schafft, den ganzen Source in Notepad zu laden und nochmal abzuspeichern - am besten lädst du das Ganze vorher nochmal runter, für den Fall, dass sich in deinem Source inzwischen andere Fehler eingeschlichen haben.
Sollte dies tatsächlich der Fehler gewesen sein, sollte man aber unbedingt drauf achten eine "Alt-Delphikompatible" Version hochzuladen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/