Bitte IMMER den Link aus dem Wiki angeben. Alle andere Links können wegfallen, sich ändern oder zusätzliche Versionen des Headers können entstehen, die so einfach nicht abgedeckt sind. Deswegen war ich auch so frei und hab den mal bei dir (waran) gelöscht.

Sonst hat waran aber durchaus recht. Der aktuelle Header unterstützt OpenGL 3.0. Leider bin ich noch nicht dazu gekommen 3.1 einzubauen. Bzw OpenGL 3 unter Linux funktioniert auch nicht.

Allerdings war das nicht deine Frage. Denn du wolltest gerne einen Header bei dem alle veralteten Methoden weg sind. Möglichkeit 1 wäre, dass man das alles per Defines im Header ausklammert, was veraltet ist. Hätte aber das Problem, dass der Header dadurch nicht übersichtlicher wird. Weil alle anderen Methoden nach wie vor noch so enthalten sind. Möglichkeit 2 wäre ein seperater Header der immer der neusten Version entspricht. Denn genau genommen können in OpenGL 3.2 auch Methoden von 3.1 als veraltet markiert werden und wegfallen. Wie ja auch bei 3.1 mit den Integer VertexAttribs von 3.0 passiert ist. Würde aber bedeuten, dass man 2 seperate Header pflegen müsste. So richtig gefallen mir beide Möglichkeiten nicht.

Bzw ist es auch so, dass ich mit den 1,5 Seiten in der Spezifikation mal gar nichts anfangen kann. Entsprechend hab ich keinen Plan was bleiben darf und was nicht. Seite 2 Monaten oder so gibt es im OpenGL Registry allerdings einen OpenGL 3 Header. Dort sind wohl nur noch die nicht veralteten Methoden enthalten. Allerdings auch nicht eine Erweiterung die nicht im Kern enthalten sind. Wobei ich auch nicht weiß ob die überhaupt noch Relevanz besitzen.

@Lossy eX
Genau das meinte ich.

Meiner Meinung nach ist die Variante mit dem ausklammern der veralteten Methoden nicht unübersichtlich, wenn man es zum Beispiel so wie in der neuesten glext.h macht.
Bz. als erstes alle gültigen Methoden aus Version 2.0 und unterhalb die deprecated Methoden aus Version 2.0 mit bedingter Kompilierung.

Andererseits wäre es sicherlich nicht falsch einen Schlussstrich zu ziehen, und einen neuen Header mit den gültigen Methoden ab V3.x zu erstellen.

Wie es mit den Extensions aussieht würde mich auch interessieren. Nur bei wenigen ARBs in den neuen Headern sind Teile mit deprecated gekennzeichnet (zb. GL_ARB_imaging).

Hi,

eine idee wäre - auch wenn das ein ziemlicher aufwand evtl wäre, es wie C++ zu machen... also in gl und glext zu trennen.

Die glext würde dann so wie aktuell die dglOpenGL.pas fortlaufen gepflegt werden. die gl.h/pas würde dann jeweils nur das beinhalten was im kern von der jeweiligen OpenGL version ist.

Sprich sobald eine neue OpenGL Version erscheint wird der bislang aktuelle Header nichtmehr weiter angefasst und stattdessen für die neue version ein neuer (ggf. aufbauend auf dem alten) angeboten.

So hätte man dann z.B.

dglOpenGL100.pas
dglOpenGL150.pas
dglOpenGL200.pas
dglOpenGL210.pas
dglOpenGL300.pas
dglOpenGL310.pas
[...]
dglOpenGLext.pas

So könnte man sich den header für die version aussuchen die man unterstüzen möchte und hat mit der ext-variante alle extensions (die ja versions-unabhängig sind) beisammen.

Aya~

Ich wollte auch Ajas Modell vorschlagen, allerdings in einer abgeschwächten Version. OpenGL 3.0 bietet uns ja die Gelegenheit einen definierten Neuanfang zu wagen.

Dementsprechend sollten wir einen dglOpenGL20 anbieten, welcher keine OpenGL3 Methoden beinhaltet aber alle alten Varianten. Dieser Header wäre dann stable und würde nicht mehr angefasst werden außer für Bugfixing.
Dazu dann entweder einen dglOpenGL30 bzw. einfach die dglOpenGL weiterführen mit nur noch OpenGL3 Funktionen. Die Frage wäre da, ob man dort bereits wieder veraltete 3er Funktionen drinnen lässt oder nicht.

Diese Lösung hätte den Charme, dass die Nutzer entscheiden können für welche OpenGL Version sie Programmieren und welchen Header sie entsprechend einsetzen. Wer 3er Funktionen benötigt, benötigt gleichzeitig keine 2er und 1er Funktionen mehr, da diese ja nicht wirklich kompatibel sind.

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

Sorry hab ne ganze Weile gebraucht. Denn ich bin mir aktuell noch so überhaupt nicht im klaren was solch eine Umstellung für Aufwand mit sich bringt und ob das alles so funktioniert wie das theoretisch sein soll. Deswegen werde ich mir sowas immer erst 3 mal überdenken bevor ich handel.

humflo: Was mich an der Übersicht stört ist, dass zu mindest ich ganz gerne mal in den Header schau um was nachzuschlagen. Und wenn man da so verschiedene große Blöcke hätte die sich alleine durch define oder nicht define unterscheiden. Das finde ich auf Dauer doch etwas komplex. Zu mal ich beim Headerpflegen immer wieder Dinge verschieben müsste etc.


Aber ich habe auch eine generelle Frage ich zu OpenGL 3.0. Das ist wohl etwas was für das Design recht wichtig sein dürfte. Wie läuft das genau bei der Kontexterstellung ab. Sagen wir ich will einen Kontext mit der Version 3.0 haben aber mein System kann schon 3.1+. Bekomme ich dann einen 3.0 Kontext oder einen 3.1? Denn dann könnte es passieren, dass auf dem einem reinen 3.0 System einige Methoden funktionieren und auf einem 3.5 System diese Methode nicht mehr nur deprecated sind sondern schlicht nicht mehr existieren. Dann wäre eine Aufsplittung in einzelne Versionen nämlich irgendwie nich so richtig sinnvoll.

Und nur so als Randbemerkung. Da dieses Modell eh erst mit 3.0 eingeführt wurde wird das auch maximal bis 3.0 zurück führen. Ein Aufsplitung vor 3.0 ist quatsch.

Hallo,

Ich habe es mittlerweile so gelöst.
- Einen neuen Header erstellt, der keine deprecated Funktionen aus OpenGL 2.1 oder kleiner enthält.
- Aber Funktionen die zb. von Version 3.0 auf 3.1 deprecated sind, sind enthalten (zb. glVertexAttribI1i).

So kann man sich dann entscheiden, will ich einen 3.0 oder 3.1 Kontext nutzten, und es ist nicht so viel arbeit als wenn man für jede Versionen eine eigenen Header hat.

Eine andere Angelegenheit bei einem neuen Header wäre noch die Delphi 2009 Kompatibilität.
Da in D2009 zb. string und PChar eigentlich WideString und PWideChar sind, gibt es mit dem Header Probleme.
Eine Änderung in AnsiString, PAnsiChar usw sollte genügen und keine Probleme bei anderen IDEs verursachen.



Wenn man mit wglCreateContextAttribsARB einen 3.0 Context erstellt bekommt man auch einen solchen, auch wenn das System eine höhere Version unterstützen würde.
Sprich man kann explizit angeben welche Version man haben möchte.

humflo

Beim erstellen gibst du Majorund Minor Nummer an, um die exakten OpenGL Context Version an zufordern.
Des weiteren ist auch wichtig, welches Profiel man anfordert denn wenn das Profiel nicht verfügbar ist, dann bekommt man auch kein Context.

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

Projekte: https://github.com/tak2004

As it seems the current version of dglopengl does not seem to work with delphi2009. Besides some warnings the function wglGetProcAddress making all opengl extensions fail to work

This is my current dglGetProcAddress (so it works again ):


I left the glx to use a simple pchar as i believe that is linux / fpc only.

_________________
http://3das.noeska.com - create adventure games without programming

Es gibt nen üblen bug, der mich ziemliche Nerven gekostet hat (siehe http://bugs.freepascal.org/view.php?id=7570), weswegen ich auf einmal Probleme mit Ati2n Normalsmaps hatte ab catalyst 9.4. Im normalen gl Header von fpc wird der umgangen mit


und


Somit ist es mit der dglopengl Unit möglich, diverse seltsame Exceptions zu bekommen (zumindest in fpc, von der Beschreibung her könnte das auch in Delphi der Fall sein), obwohl keine Fehler vorhanden sind. Ich denke man sollte dies schnellstmöglichst beheben.

Ich habe auch noch eine weitere Bitte: Editiert doch mal den ersten Beitrag und den Namen des Themas, ich habe erst durch Zufall gesehen, dass es eine neuere Version des Headers gibt...

Erstmal danke für die Änderung des Thementitels

Also ich habe nochmal etwas nachgeforscht, da

ja eigentlich das selbe machen sollte. Es stellt sich heraus, wenn man die Set8087CW Funktion von der fpc math unit nimmt, klappt es. Nutzt man die in der dglopenl definierte, hat es seit catalyst 9.4 keinen Effekt mehr.

Ich habe nochmal einen simplen Test gemacht und das standard sdl template (http://wiki.delphigl.com/index.php/Archiv:template_delphi_sdl) so umgeschrieben, dass es eine ATI2N Texture läd. Ihr braucht dafür die vampire imaging library (http://imaginglib.sourceforge.net/). Und eine ATI2N texture (genannt test.dds), kann man einfach mit Gimp erstellen (anhängen ging nicht, da falsche Endung). EDIT: Ist völlig egal, ihr könnt auch .jpg nehmen, da ich gesagt hatte, dass das gewünschte Format ATI2N sein soll... /EDIT. Ihr solltet die dglopengl.pas noch austauschen und auch {$mode delphi} in die sdl.pas schreiben bzw. die neuere nehmen, die bei freepascal dabei ist.

Den Code des Beispiels hab ich wie folgt geändert:

Compileroption

Neue Units


Neue Variable:


Textur in die Szene eingebaut:


ATI2N Textur laden (ggf. Endung ändern, Zielformat ist immer ATI2N):


Vor der Hauptschleife im Programm


Getestet hab ich jetzt mit dem Programm nur auf Vista auf ner 4570 mobility und catalyst 9.5, das Problem hatte ich aber mit ner 4850 unter XP64 auch schon mit catalyst 9.4 und 9.5.

Edit: Zielformat ifDXT3 und ifDXT5 crasht auch, ifDXT1 geht, ifATI1N geht auch.

Erst mal danke, dass du dir so viel Mühe gemacht um das mit Set8087CW rauszufinden. Ich habe schon immer gefragt was das für einen Sinn haben soll, da die Methode aus der dglOpenGL lediglich eine Konstante überschreibt. Gerade hatte ich aber gesehen, dass in Delphi noch befehle der fpu aufgerufen werden. Ich werde das entsprechend anpassen.

Allderdings zu deinem letzten Post. Nicht falsch verstehen aber was zum Geier willst du damit sagen? Sorry aber ich verstehe es absolut nicht.

Keine Ursache, ich dachte wenn ich schon so lange gesucht habe sollen andere sich nicht auch noch drüber ärgern müssen...

Bez des letzten Beitrag: Das sollte es nur einfach machen, damit ihr das nachvollziehen könnt, außerdem hatte ich mich sowieso gefragt, ob er auch beim simplen Texturbinden crasht (evtl kommen ja noch mehr Faktoren hinzu). Jetzt hab ich einfach für Faule etwas Code gepostet, da kann jeder selbst den Fehler reproduzieren, sofern er die entsprechende Hardware hat.

OpenGL 3.2 - Headertranslation
Version 3.2.2
Date : 16.12.2009

row 6577 should be:
TglGetAttribLocation = function(programObj: GLhandle; char: PGLChar): glint; {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}

_________________
http://3das.noeska.com - create adventure games without programming

Ich hab die Versionsgeschichte mal aktualisiert. Die letzten 4 Änderungen waren nicht aufgeführt und es sah aus, als wäre der Header noch von 2007.

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