Schaut euch mal folgendes ARB-Meeting vom 10/11.6.2003 an : <a href='http://www.opengl.org/developers/about/arb/notes/meeting_note_2003-06-10.html' target='_blank'>http://www.opengl.org/developers/about/arb...2003-06-10.html</a>
Und lest euch da mal den Paragraphen zum Thema "Next OpenGL Revision" durch (fast ganz am Ende)...dort wird von einer Coreversion 1.5 geredet :

So wie die Sache dort rüberkommt (besonders der letzte Satz und das perhaps) könnte es möglich sein das OpenGL 2.0 doch noch in die Ferne rückt :angry:

Allerdings werden in OpenGL 1.5 einige interessante Extensions mit in den Core eingehen :
- ARB_vertex_buffer_object
- EXT_shadow_funcs
- NV_point_sprite
- ARB_occlusion_query

Da bin ich jetzt echt mal gespannt ob das ARB endlich mal in die Gänge kommt, denn langsam wirds echt Zeit...hoffentlich wird das nächste ARB-Meeting (erst im September) da erfolgreicher.

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

Naja wenigstens gibt's ja bald dann glSlang. Ob das dann OpenGL 2 heißt oder ob glSlang eine Extension zu OpenGL 1.5 ist, ist mir eigentlich egal.
Schade nur das die Über Buffer noch eine gewisse Zeit dauern. Hoffentlich sind die dann im September fertig.

Mal so eine Frage in den Raum geworfen. Wie reagieren wir auf die Meldung von OpenGL 1.5? Was ist aus der Idee geworden die entsprechende Unit für OpenGL2 zusammen mit den Spezifikationen von 1.x zusammen zu setzen. Bietet sich das vielleicht nicht auch schon für 1.5 an?

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

Ich persönlich wäre schon dafür, auch entsprechende OpenGL1.5-Header zu erstellen.Allerdings können wir uns mit dieser Entscheidung nich ein wenig Zeit lassen, da vor dem nächsten ARB-Meeting im September wohl kaum was in der Richtung passieren wird, zumal dann auch die Grafikkartenhersteller noch entsprechende Treiber bereitstellen müssen.

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

Ja, sollte auch keine Hektik sein, vielmehr die allgemeine Resonanz hier in der Gruppe, ob man so etwas in Angriff nehmen möchte und natürlich auch mag. Wie siehts eigentlich aus. Ich denke wir haben hier einen recht harten Kern. Ich stelle mal unverfroren die Frage, ob die hier anwesenden sich die Arbeit zutrauen oder jemand das Gefühl hat, dass man noch jemanden aus dem "Pool" benötigen könnte? Ich meine für mich steht die Entscheidung praktisch fest, aber... des Protokolls wegen

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

Ich denke OpenGL 1.5 sollte kein großes Problem sein, wenn wir opengl12.pas mit Extensions von Lossy eX als Grundlage nehmen. Das ist ja so eine Art OpenGL 1.4 mit Extensions. (@Lossy eX: Natürlich nur wenn das in Ordnung ist.)
Es werden ja jetzt viele bestehende Extensions als ARB Version anerkannt und die Namen zu ändern dürfte eher ein geringerer Aufwand sein. Den Rest teilen wir dann eben auf und jeder macht dann seine Extension. In ein paar Stunden sollte das dann fertig sein und dann fügen wir die Datei nur noch zusammen.

Na klar ist das in Ordnung. Warum sollte das auch nicht so sein.
Allerdings drängt sich mir gerade wieder die Frage auf, ob wir das in die OpenGL12.pas einpfegen wollten? Bestimmt oder wäre es besser, wenn man einen OpenGl14.pas und eine Opengl15.pas macht. Was aber wieder eine doofe programmiertechnische Sache wäre.
Ich für meinen Teil hätte da nix gegen, die Extensions einfach so dort rein zu kopieren. Allerdings sollten wir dann vorher aber mal die rechtliche Seite klären!
Ich habe die Extensions ja nicht ohne Grund in einen extra Header gepackt. Ich weiß jetzt nicht genau unter welcher Lizenz Mike Lischke seinen Header veröffentlicht hat und ob wir den einfach so verändern dürfen! Wenn dem nicht so ist sollten wir das mit Mike auf jeden Fall mal abklären ob wir eine Genehmigung von ihm bekommen.

Was spricht dagegen eine opengl15 zu machen? Verwirrt vielleicht auch einige Leute weniger, wenn man nicht ne openg12 auf dem Stand von einer Opengl14 hat.

Ich denke aber auch, dass wir uns mal genau überlegen wollen, wie wir die opengl15 oder auch die opengl20 aufsetzen wollen, damit wir eben solche Dinge wie die Lizens abklären können. Sehe da selbst wenig Probleme mit Mike, aber ... ich bin halt immer Pessimist

btw: Schön zu sehen, dass ihr auch alle hier drinne seid Willkommen

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

Meiner Meinung nach ist das einfacher, wenn wir alles in eine Datei packen, denn die Opengl12.pas enthält ja auch die Funktionen von OpenGL 1.1 . Dann braucht man nur eine unit einbinden. Kann Mike Lischke überhaupt die Rechte an dem Header besitzen? Er hat das ja auch nur konvertiert und in der original gl.h steht SGI als Copyright Besitzer.
Eine andere Idee wäre die Standard opengl.pas von Delphi als Grundlage zu nehmen, die ja glaube ich OpenGL 1.0 entspricht und dort die entsprechenden Funktionen bis zu OpenGL 1.2, die Extensions von Lossy eX und die neuen OpenGL 1.5 Extensions einzufügen. Da wäre ja hauptsächlich eine Kopieren.
Zusätzlich sind bei Mike Lischkes Header noch so Hilfsfunktionen drin. ActivateRenderContext ist ziemlich langsam habe ich festgestellt und diese ganzen Zusatzfunktionen haben eigentlich nichts in einer Header Datei zu suchen.

Ja das ist so eine Sache ich weiß auch nicht genau ob mal auf so etwas eine lizenz packen kann. Allerdings hat er ja auch solche Dinge gemacht wie die Hilffunktionen.

Wenn wir die einzelnen OpenGL Versionen jeweils in eine eigene Datei packen dann sollte es auch keine Komplikationen mit der rechtlichen Seite geben. Allerdings finde ich das für Entwickler irgendwie doof. Wobei das auch kein großes Problem ist. Evtl. kann man ja auch ein Paket machen indem opengl12.pas, opengl14.pas, opengl15.pas und eine Opengl.pas sich drin befinden. Diese könnte ja dann die Lademethoden der anderen aufrufen. Allerdings weiß ich nicht so genau, wie das sich dann mit den Typen und methoden verhält. Müsste man mal ausprobieren.

Also wenn ich das so lese, tendiere ich doch irgendwie zu einer ein Datei-Lösung. Das andere klingt eigentlich nur für Leute interessant, die wenn auch genau wissen was in welcher Version von OpenGL enthalten ist. Ich denke, dass das ein wenig sehr komplex werden könnte. Wenn überhaupt könnte ich mir etwas mit ner Include-Datei vorstellen, wo man dann einstellt bis welche Version die Header unterstützt werden und dann entsprechend includiert werden. Könnte schwören sowas bei den JEDIs mal irgendwo vgesehen zu haben.

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

Ich bin auch defintiv für eine Datei, was sich allein schon aufgrund der Rückwärtskompatibilität von OpenGL auf ältere Coreversionen anbietet.
Eine Lösung aus mehreren Units wäre in meinen Augen eher störend und würde die Sache umständlicher machen.

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

Was SoS meint, ist ja genau der Vorteil von OpenGL. Man hat ja nicht wie bei DirectX für jede Version ein anderes Interface und auch OpenGL 2.0 soll ja erstmal voll abwärtskompatible sein. Wenn man opengl15.pas einbindet aber die neuen Funktionen nicht benutzt ist das ja auch nicht weiter schlimm. Wenn man die Hilfsfunktionen aus der OpenGL12.pas wieder entfernt, dann wäre das eine gute Grundlage. Selbstverständlich sollte man Mike Lischke dann trotzdem noch mit erwähnen. Auch in Hinsicht auf Demos und Tutorials wäre das sinnvoll eine Standard Unit mit allem zu haben. Sonst müßte ja bei Tutorials die bestimmte Extensions als Thema haben speziell, auf irgendeine Zusatzunit hingewiesen werden und verschiedene Tutorials haben dann eventuell verschiedene Extension Units. Das ist für jemand der bestimmte Techniken selber austesten möchte umständlich. Da wäre es besser die opengl15.pas, dann als DGL Standard oder so zu definieren.

Ja, ich denke genau das Argument ist auch das ausschlaggebende. Das Interessant wäre eben eine Unit zu haben die man als Referenz angeben kann ohne das es dabei ein ähnliches Versions wirrwarr gibt, wie es momentan oft das Fall ist. Ich denke auch, dass z.B viele es begrüßen würden, wenn sowohl gluint als auch TGlutInt in dieser Unit definiert sind. Schlichtweg, weil Mikes Units bewirken, dass Source Code meist geändert werden muss. Allerdings ist damit ja der gesamte Sinn dieser extra Namensvergabe hinfällig. Warum also nicht etwas, was beides akzeptiert. Die Hilfsunits könnte man ja evtl. in eine zweite Unit setzen, so dass man das von den eigentlichen Header trennt, dennoch nicht darauf verzichten muss und in diesem Fall auch den Anwender die Wahl überlassen wird, ob er sie einbinden will oder eben nicht.

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

Ich bin auch der Meinung, daß es eine gute Idee ist, unabhängig vom Header noch eine Zusatzunit mit Funktionen anzubieten. Diese Funktionen sollten dann möglichst unabhängig voneinander und möglichst universell sein. Ein Beispiel wäre die CreateRenderContext Function von Mike Lischke. Damit meine ich auf keinen Fall eine komplexe Klassenhierachie, einen Texturemanager oder gar so etwas wie GLScene, sondern Funktionen die in jede Demo und in jede Engine passen.

Zum Beispiel eine Funktion, die ein Bild aus einem TBitmap lädt, ein OpenGL Texture Object erstellt, die nötigen Paramter einstellt und dann die Texture lädt.



Hier sollte man bewußt drauf verzichten aus Dateien zu laden, weil die Funktion dann nicht mehr so vielfältig einsetzbar wäre. Es sollen eben Funktionen sein, die jede Engine überdauern, weil sie eine ganz bestimmte Aufgabe in optimaler Art und Weise ausführen.

Mit dieser Funktion kann man auch Cubemaps laden, weil eben der target Paramter angegen ist.
Man könnte auch noch weitere Funktionen so in der Art definieren.



Ich denke diese Liste läßt sich noch um einiges erweitern.

Jedenfalls würde das Einsteigern auf jeden Fall helfen, wenn sie zu den häufigsten Problem gleich Quellcode dabei hätten.
Man könnte die unit dann ja glutils.pas nennen.
Was meint ihr dazu?