Hi,
1. Ich habe versucht die aktuellen Header unter Linux zum laufen zu kriegen. Ich habe den Eindruck, dass etwas mit den Bindings von OpenGL nicht ganz funktioniert und das entsprechend mit einer Expetion quittiert wird (als würde OpenGLInit nicht aufgerufen werden). Ich werde mal versuchen die Tage das ein wenig einzugrenzen.
2. Dann habe ich von einem Dänen zwei Dateien mit Patches bekommen für GLX/Linux-Support. Bin nicht wirklich in den Header drinne, aber könnte morgen einmal versuchen die Patches einzuspielen und zu offen, dass sich Punkt 1 damit auch erledigt hat. Für jene, die sich interessieren anbei einmal die Patch-Dateien (hoffentlich bekommt ihr die gescheit geöffnet).

Sollte ich hier also einem Phantomfehler hinterher jagen und das in irgend einer Form vielleicht an meinem System liegen.... es also bereits jemanden von Euch gibt, der erfolgreich ein Linux-Kompilat mit den dglheadern erzeugt hat, so möge er dies bitte hier kundtun

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

Dauert bei mir alles ein wenig länger, aber für den Fall, dass es bisher nirgends bestätigt wurde: Unsere Header sind nun lauffähig unter Linux mit SDL und fpc.

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

Wie hängt das mit der .Net Betaversion zusammen? Müssen da die Änderungen auch noch durchgeführt werden?

Nein, scheinbar nicht. Ich bin mir nicht sicher, was sich bei den letzten Updates der w32-header verändert hat, aber der Aufruf einer Anwendung wird nicht mehr mit einer abstürzenden Konsole beantwortet. Zumindest ein Dreieck kann dargestellt werden Sollte die .NET-Beta also auf den letzten Header basieren, sollten keine Änderungen mehr notwendig sein. Die Beta selbst scheiterten bisher mangels eines Pascal-Compilers unter Linux :-/

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

Soweit ich das mitbekommen habe, hatte Bero den Header bereits in der Version vor .Net für Linux tauglich gemacht.

Also läuft der .Net Beta Header mit FP unter Linux ? Nicht das wir dann nacher zwei Versionszweige haben.

Ja, allerdings gab es bisher zumindest hier bei mir stets noch Probleme... gibt ja leider nicht viele, die es wirklich getestet haben.
@beta: Aehm, jein. Zunächst einmal beklagt sich FPC darüber, die Optionen $O und $A nicht zu kennen, gibt ein Warning aus und setzt fort. Danach hagelt es eine schier endlos lange Liste an Fehlermeldungen, da die Bezeichner nicht gefunden werden. Einige Abfragen scheinen nur zu vergleichen, ob CLR unterstützt wird und anschließend als alternative sofort mit der Windows-Initalisierung beginnt. Entsprechend setzt der Compilier bei den WGL-Funktionen Fragezeichen, da diese alle Standardmäßig eingebunden werden. Habe ja nicht viel Ahnung und denken fällt, schwer, also habe ich einfach drauf los gelegt die Blöcke, die Probleme machen als W32 zu definieren und nach einigen Änderungen liess sich der Header kompilieren und eine damit kompilierte Anwendung genauso gut starten. Denke also, dass einzig und alleine die wgl-Funktionen ausgeklammert werden müßten. Hänge Dir einmal ein .diff-File an, hoffe, dass Du etwas hast um das verständlich anzuzeigen (Eclipse?). Ansonsten also gut...
einzig und alleine fällt mir momentan auf, dass scheinbar auch keine GLX-Funktionen (Gegenstück zu WGL) implementiert sind. Da ich das ganze über SDL teste, funktioniert es dennoch einwandfrei. Allerdings sollte man diese evtl. auch einfügen. Habe irgendwo noch einen alten Versuch von Nico rumfliegen und werde den evtl. mal die Tage versuchen mit einzubinden.

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

Die glx Funktion müssen dann noch auf jeden Fall mit rein. Hatte mich bei der Bearbeitung auch gewundert, warum da keine drin sind. Die SDL kann auch einzubinden ist eigentlich keine schlechte Idee. Ich denke aber mal das wird dann auf den nicht .Net Teil beschränkt sein oder?
Ich habe kein Programm mit dem man dif Dateien anwenden kann. Kannst du vielleicht direkt die .Net Version, die auch unter Linux läuft anhängen. Das wäre ja dann die aktuellste Version des Headers und die werd ich dann gleich mal in dem .Net Header Thread updaten.
Die Blöcke müßten als Win32CLR deklariert werden, weil Win32 unter .Net nicht unbedingt definiert ist und vorne im Header die Konstante Win32CLR definiert wird, wenn eines der beiden aktiv ist.

SDL hielte ich für eine sehr schlechte Idee. Zum einen hat das mit OpenGL ja nichts am Hut und zweitens haben wir sowieso schon einen Monsterheader und sollten Dankbar sein, dass die Jedis sich bisher darum kümmern. Eine Anpassung kann ich vornehmen und anhängen, allerdings ungerne mit der Version, die ich Quick&Dirty nahe der Nacht gemacht habe. Bist Du Dir 100% sicher, dass es überall Win32CLR sein muss? Einige der Bereiche sahen (also die ohne TWGL) sahen mir eher nach reinem Win32 aus.

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

Die wgl Funktionen werden ja auch unter .Net benötigt. Außer den beiden wglUseFont* Funktionen war glaube ich alles dabei. Wenn es im else Zweig von Win32 ist, müßte es ja unter .Net sowieso schon mit kompiliert worden sein. Man kann ja erstmal Win32CLR benutzen damit es unter Linux läuft und danach dann schauen was unter .Net Probleme bereitet und das wieder rausnehmen.

Achso... nun langsam begreife ich. Win32CLR gilt auch für die Win32? Dachte, dass Win32 für alle gilt und Win32CLR nur explizit für die .NET-User. Habe mir gerade die GLX-Header von Nico angesehen. Das wird ne Tick aufwendiger werden und komme frühsten gegen Ende der Woche dazu. Damit das ganze hier nicht rumgammelt hier schon einmal die angepaßte Version, die unter Linux und FPC läuft. Habe entsprechend neue Defs mit einem //Phobeus versehen, damit Du via Suche darauf zu greifen kannst. Bitte einmal austesten und auch alle Punkte einmal durchgehen. Stecke nicht wirklich gut in den Header drinne und habe schlichtweg alles was WGL bzw. irgendwelche Windows-Dinge eingebunden hat, ausgeklammert. Nicht, dass ich irgendwo was falsches entfernt habe. Daher am besten die Header einmal durchgehen und dann auch gleich meine Kommentare wieder entfernen. Wenn es dann auch bei Dir läuft bescheid geben und ich werde mal zusehen, wie man hübsch die GLX dazu bekommt.

Übrigens ganz nebenbei. Man merkt zumindest bei fpc merklich, dass die Header enorm aufgebläht sind. Aus ca. 2 Sekunden werden immerhin 9 Sekunden Kompilation. Bringt es erhebliche Geschwindigkeitseinbussen, dass soviele Defs enthalten sind bzw. der Linux-Nutzer soviel Ballast aus der Windows-Welt in einer Datei mit sich rumschleppt? Wenn es evtl. etwas bringen könnte, könnte man ja mal in einem Skript-Forum (Python?) ein paar Newbs ein Skript in Auftrag geben, dass via Zielsystem "linux/fpc;win32/fpc;delphi;delphi.net" aus den Headern eine angepaßte kleinere Version macht, die dann halt nur noch auf einem Zielsystem läuft. Nicht als Ersatz der "universal-Header", aber vielleicht ein Gimmick für unsere SDKs? Oder würde so etwas vermutlich kaum einen merkbaren Unterschied machen?

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

Ich vermute mal das die ganzen Stubs, die ja ca 12.000 Zeilen ausmachen dafür verantwortlich sind. Ich habe mir den FP Quelltext mal angesehen und ein ziemliches Durcheinander vorgefunden. Bero hat mal etwas tiefer hineingesehen und der Scanner von FP ist ziemlich schlecht. Die verwenden keinerlei Hash oder Baum um die Schlüsselwörter zu identifizieren. Daher denke ich, dass es an der Größe und an FP liegt. Ohne $IFDEFs wäre es vermutlich etwas schneller, aber da man das ja nur einmal kompilieren muß und dann als Unit hat, denke ich dass das besser ist, als ein extra Script zu schreiben, dass ja faktisch genau das gleiche wie der Compiler macht, der ja im Idealfall die dglopengl.pas auch nur einmal kompiliert. Mir gefallen die vielen $IFDEFs da auch nicht, aber das ist halt die Plattformunabhängigkeit. Selbst auf meinem alten Rechner mit Athlon 2000 und 512MB kompiliert Delphi 2005 den Header sehr flott (2..3 Sekunden). Allerdings sind die ganzen Stubs ja nur wegen .Net dadrin obwohl es auch ansonsten eine schöne Sache ist. Aber was sind schon einmalig 9 Sekunden, gegenüber dem Aufwand mit einer zusätzlichen Datei. Also mir wäre es zuviel Aufwand.
Werde den Header mal durchtesten.

Hab mit dem Template getestet und der Header hat auf Anhieb funktioniert.

Auch für Win32? Das wäre dann ja durchaus bereits erbaulich. Werde mal schauen, was man mit GLX macht, muss mich da selbst aber erstmal einlesen, weil ich bisher stets SDL bevorzugte. Aber da wir bereits eine laufende Lösung haben... gibt aber wieder einige neue Konstanten. Hoffentlich geben nicht irgendwann die Compiler auf

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

An Win32 habe ich gar mehr gedacht. Das existiert für mich schon gar nicht mehr. Werde den Header da aber auch nochmal testen.

Habe den deine Version ins .Net Forum gestellt.