Kleine Vorgeschichte:
Ich hatte ja schon vor einiger Zeit geschafft, dglOpenGL unter Mac OS zum Laufen zu kriegen (und mit SDL ist auch alles perfekt); da vor ein paar Tagen im PGD die Frage aufkam, ob es möglich wäre, Asphyre/Andorra2D/Phoenix unter Mac OS X zu verwenden, hab ich mal angefangen, die veraltete glfw.pas für Mac OS X anzupassen. Und wo ich schon dabei war, habe ich mal an die API an die Version 2.6 angepasst (waren eigentlich kaum Veränderungen, wundert mich, dass es niemand schon früher gemacht hat). Das alles funktioniert auch ganz gut, das mitgelieferte Beispiel läuft ohne Probleme, allerdings nur wenn ich die gl.pas und glu.pas benutze.

Das aktuelle Problem:
Sobald ich die dglOpenGL.pas einbinde, kompiliert es einwandfrei und manchmal startet die Anwendung auch und alles läuft, aber eben manchmal aber auch nicht und spätestens nachdem ich mein Testprogramm etwa fünfmal aufgerufen habe, geht es nicht mehr und lässt es sich erst wieder starten, wenn ich den Quelltext neu kompiliert habe.

Unter Windows gibt es keine Probleme, ich werde es nachher noch unter Linux testen.
Hat vielleicht jemand eine Idee, woran es liegen könnte?
(Ich habe mal das angehängt, was ich fabriziert habe, eventuell fällt doch jemanden eine Lösung ein.)

Update: Grade unter Linux getestet, es läuft, aber nur, wenn ich die ReadImplementationProperties beim Laden nicht aufrufe.

_________________
[http://www.freeze-dev.de]

Habs unter Windows XP Prof getestet, läuft (aber nicht Deine mitgeschickte exe, die läuft bei mir nicht).

Unter Linux läuft das Ganze bei mir überhaupt nicht. Ich musste vorher die glfw bei mir installieren, die gab es in meinem System gar nicht. Die Library heißt libglfw.so.2.6, klar kann er die nicht finden, dh. ich müsste Dein Beispiel erst hier für mich anpassen, würde also länger dauern.

Hm, das Ding stürzt bei Dir nicht ab, wenn Du steinalte Bibliotheken verwendest. Da ich soeben die glfw.2.6 bei mir installiert habe, habe ich folgendes gesehen: http://packages.ubuntu.com/source/intrepid/glfw

glfw braucht im Untergrund ein paar moderne Zusatz-Bibliotheken, besonders wenn man unseren Header verwendet (ReadImplementationProperties ist wahrscheinlich ganz schön heavy ). Hast Du die alle installiert?

Ich hatte es heute früh unter Ubuntu 9.04 getestet, eigentlich sollte ein symbolischer Link von der libglfw.so.2.6 namens libglfw.so existieren, der aber nicht funktioniert. Ich hatte dann in der glfw.pas const DLLNAME auf 'libglfw.so.2' geändert und dann ging es. Ich werde mal prüfen, ob es bei anderen Distributionen genauso ist.


Ich habe nur eine integrierte Intel GMA X3100 in meinem MacBook, also nicht gerade das Flagschiff bezüglich OpenGL-Anwendungen.
Ich hatte das libglfw-dev Paket installiert, normalerweise müsste der Paketmanager alles relevante gleich mitinstallieren. Was ich da allerdings komisch finde, dass wenn ich den Header zusammen mit der SDL benutze, kann ich auch ohne Probleme ReadImplementationProperties aufrufen, ohne dass ich eine Invalid Pointer Exception bekomme.

_________________
[http://www.freeze-dev.de]

Detto bei mir. eine DirectX9 fähige Grafikkarte, NVidia 6600GT. Aber OpenGL funktioniert ganz ordentlich sowohl in Linux als auch in Windows bei mir: er kann eine Framerate von über 1000 erreichen, allerdings ohne Anti-Aliasing.

Ich habe libglfw2 (2.6-1) und libglfw-dev (2.6-1) installiert. Aber Lazarus gibt mir einen Linker-Error, obwohl ich den DLLNAME ebenfalls richtiggestellt habe. Leider verrät mir Lazarus nicht, wo genau es jetzt hakt.

Mac kann ich nicht testen, denn ich habe keinen Mac.

Ich wollte noch sagen, dass ich normalerweise nicht glfw verwende. Ich habe eine Basis selbst in purem Pascal geschrieben, und als ich draufkam, dass es so etwas wie glfw gibt, hatte ich das Zeug in Windows schon fertig. Im Prinzip ist das, was ich habe, eine Untermenge von glfw, in Pascal geschrieben. Als ich dann schon soweit war, habe ich Linux/X11 Server mitgemacht. Ich brauche daher kein glfw, sondern nur die Zusatzbibliothen glx und XRandr. Das gibt es in FPC auch. Allerdings ist die glx Bibliothek dort veraltet, es gibt schon glx 1.4 (oder vielleicht in der Zwischeinzeit auch schon höher) aber mein FPC 2.2.2 hatte immer noch Version 1.1. Das Hochziehen auf die neueste Version war eigentlich kein großes Problem.

Man braucht nicht die ganze Palette von glfw, platformunabhängige Threads gibt es in FPC ja auch.
Viele Grüße,
Traude

Aus dem Menü bei Projekt -> Compilereinstellungen im Registerreiter Linken unter Einstellungen die Checkbox anklicken und dann dort im Feld eingeben: -lGL -lGLU -lXrandr
Erfordert noch die Installation des Pakets xrandr-dev (kann auch libxrandr-dev heißen, hab ich nicht mehr genau im Kopf) über den Paketmanager.

_________________
[http://www.freeze-dev.de]

Danke, ich probier es aus. Kann aber erst morgen, ich erstatte dann Bericht, ob es funktioniert hat.
Xrandr-dev ist installiert.

Ich habe es mit Deinen Linker-Parametern probiert, ich bekomme aber immer noch einen Linker-Error.

Sieht so aus, als müssste ich ein wenig tiefer in die Materie hinein.

Aber etwas ist mir aufgefallen: Bei meiner händischen Methode, einen RC in Linux aufzusetzen, verwende ich ja auch die dglOpenGL.Pas. Das mache ich so:



"Read OpenGL Core" habe ich bei Dir nicht gesehen. Versuchs mal. Aber ich kann nichts versprechen. Es ist bestimmt so, dass glfw im Hintergrund seine eigenen Grafikroutinen lädt. Zum Beispiel muss er ja die ganzen glxRoutinen laden, das macht unser Header nämlich nicht. (glx ist das Gegenstück zu wgl).

Und dann lädt er ja sicher auch noch die OpenGL-Routinen. Und dglOpenGl.pas macht das NOCH EINMAL. Keine Ahnung, ob das intern irgendwelche negativen Auswirkungen hat.






EDIT: Ich habe den Linker Error gefunden: eine fehlerhafte Verknüpfung der libglfw.so, behoben habe ich das so:



nach einem Muster gefunden bei der Dokumentation zur Installation von Andorra2D mit Lazarus, Thx Andorra bzw. dem freundlichen Menschen, der das geschrieben hat.

Im Augenblick ist es so:. Zunächst bin ich in der "dglOpenglPas.procedure ReadCoreVersion" gesteckt, jetzt zeigt er ein Fenster an aber er schafft es nicht, das Dreieck anzuzeigen. Er stürzt ab mit der Fehlermeldung "SIGFPE".

Derzeit habe ich noch keine Ahnung, was sich da im Hintergrund abspielt. Weitermachen kann ich leider erst wieder nächste Woche.

Das ist komisch, ich benutze eigentlich auch recht selten Lazarus, sondern kompiliere grundsätzlich über die Kommandozeile. Einfach in das Verzeichnis "examples" navigieren und dann eingeben:

Probier das mal aus... Welche FPC und Lazarus Version hast du?


Ich hab damit mal ein bisschen rumgespielt, InitOpenGL und ReadExtensions und/oder ReadOpenGLCore muss ich aufrufen, sonst bekomme ich eine Exception. Ob ich ReadOpenGLCore dabei statt ReadExtensions oder zusätzlich dazu aufrufe, macht dabei keinen Unterschied.


Übrigens habe ich die Problemquelle vom Anfangspost ausfindig gemacht, es ist ähnlich mit folgenden dem Problem: viewtopic.php?p=72294#72294
Sobald ich im dglOpenGL.pas die Stelle

durch

ersetze (und zuvor die unit math von fpc einbinde), läuft es unter Mac OS auch einwandfrei ohne plötzliche Abstürze.

_________________
[http://www.freeze-dev.de]

Ich habe Lazarus 0.9.26 und FPC 2.2.2. Ich habe den Linker Error schon gefunden, siehe oben.


So JETZT FUNKTIONIERT ES. Dein Hinweis mit dem mathematische Koprozessor wars. Ausserdem ist er gesteckt bei der Berechnung der FPS. Ich habe einfach die Berechnung der FPS in der "Triangle.dpr" auskommentiert:




Um ganz sicher zu gehen, habe ich das Programm 10 mal hintereinander aufgerufen. Es beendet sich jedesmal fehlerlos.

Der Fehler liegt also irgendwo bei der Berechnung der FPS. Reicht Dir das?

Sorry, Doppelpost.

Ich schaffe es einfach nicht, Bugs auf sich beruhen zu lassen. Da ich jetzt wusste, wo ich suchen muss, habe ich das Problem auf zwei Zeilen eingeengt:

Das habe ich zum Anlass genommen, mir die Funktion "glfwSetWindowTitle" in der glfw.pas anzuschauen. Bei dieser Gelegenheit bin ich draufgekommen, dass ich zwischendurch mal die glfw.pas aus Andorra2D "untergeschoben" hatte. Blöder Fehler meinerseits . Die sieht nämlich ein weinig anders aus als Deine:

Andorra2D:

Stoney:


Als ich das richtiggestellt hatte, funktionierte die Kompilierung der "Triangle.dpr" ohne jeden weiteren Fehler. Ich habe Heaptrace mitlaufen lassen, alles OK.

System1: Ubuntu 8.04(Hardy Heron), Lazarus 0.9.26, FPC 2.2.2
System2: Windows XP Prof SP2, Delphi7


Es bleibt allerdings noch das Problem mit ReadImplementationProperties. Das verschiebe ich aber jetzt wirklich auf nächste Woche.


Viele Grüße, Traude

Das solltest du nicht machen, weil meine Unit auf GLFW 2.6 aufbaut, während die vom Andorra2D noch die alte Version ist, die "nur" auf die API-Version 2.5 aufbaut. Es sollte eigentlich keinen Unterschied machen, weil es kaum Änderungen im Header gab, aber sicher ist sicher


Ich hab jetzt mal alle bisherigen Änderungen zusammengefasst und das Mipmaps-Beispiel noch schnell übersetzt und daraus ein kleines ZIP-Paket geschnürt, hier zum Download.
Danke für das Testen bis her.

Kleine Randbemerkung noch wegen ReadImplementationProperties:

System 1 (MacBook Core 2 Duo 2GHz, 4 GB RAM, Intel GMA X3100)
Windows -> ReadImplemationProperties funktioniert
Linux (Ubuntu 9.04, 32 bit) -> ReadImplemationProperties funktioniert nicht
Mac OS X 10.5.7 -> ReadImplemationProperties funktioniert nicht

System 2 (AMD X2 BE 2400, 4 GB RAM, ATI Radeon 3650)
Windows -> ReadImplemationProperties funktioniert
Linux (Ubuntu 9.04, 64 bit) -> ReadImplemationProperties funktioniert

_________________
[http://www.freeze-dev.de]

Puh, ich bin im Rückstand. War heute noch mit etwas Anderem beschäftigt, aber morgen möchte ich hier weitermachen. Ich würde nämlich auch gerne glfw in Linux in Betrieb nehmen können. Meine Marschrichtung: Ich werden mir als erstes *glfwInit* genau ansehen, vielleicht krieg ich was raus.


Das sieht jedenfalls merkwürdig aus.

Ich melde mich wieder,
Viele Grüße,
Traude

Tut mir leid wegen der Verspätung, aber dafür hier ein Bericht betreffend die Probleme mit glfw und eine Lösung dazu.

Ich beziehe mich auf die "Triangle.dpr", und hier auf die folgenden Zeilen:
die gleich zu Anfang im Text stehen. Da es in Windows funktioniert hat, habe ich mich mal auf Linux konzentriert.

Die Probleme treten in der Funktion dglOpenGL.pas/ReadImplementationProperties/TrimAndSplitVersionString.

Diese Funktion bringt keinen Versionsstring zurück, sondern nur einen leeren String. Ist auch ganz klar warum: ReadImplementationProperties braucht einen gültigen Rendering Context, und nach dem Aufruf von InitOpenGL existiert noch kein gültiger RC, den muss man sich vom Betriebssystem anfordern, denn das macht die Funktion "CreateRenderingContext", aber die ist nur für Windows definiert.

Der normale Vorgang wäre, nach dem InitOpenGL sich einen (betriebssystemabhängigen) RC anzufordern, das macht die Triangle.dpr aber nicht.

An dieser Stelle begann ich mich zu wundern, warum es eigentlich so in Windows funktioniert. Und ich kam drauf, dass es Windows auch gar nicht funktioniert, ES SIEHT NUR SO AUS, als ob es funktioniert. In Windows verhaspelt sich die Funktion "TrimAndSplitVersionString" genauso wie in Linux, aber sie fängt sich nochmal und läuft ein zweites mal an. Im OpenGL-Versionsstring steht dann drin: "1.2.2.0 Microsoft Corporation", und mit dieser Angabe macht er dann weiter .

Die Lösung des Problems ist ganz einfach: man nehme die beiden Zeilen:
und versetze sie an eine Stelle, wo garantiert schon ein RC vorhanden ist, nämlich nach dem Erzeugen des Fensters:


In Linux funktionierts sodann ohne Absturz, denn jetzt werden die Funktionspointer in der dglOpenGL.pas richtig ausgelesen, sowohl in Windows, als auch in Linux.

Vorbehaltlich dessen, was Lossy Ex dazu zu sagen hat, würde ich vorschlagen, dass man bei der Benutzung von glfw immer so vorgeht. Allerdings befürchte ich, dass er dazu nicht wirklich Auskunft geben will, denn dazu müsste man sich glfw "in Depth" ansehen. Das habe ich auch nicht gemacht, sondern habe einfach angenommen, dass es anlässlich der Erzeugung des Fensters einen RC herstellt (wo auch sonst?), und es somit sichergestellt ist, dass ReadImplementationProperties seine Arbeit tun kann.

Was kann dabei passieren: es werden vermutlich die Funktionenpointer (oder eine Teilmenge davon) doppelt eingelesen, zuerst von glfw, dann von dglOpenGL.pas.
Viele Grüße,
Traude

Möchte mich auch Entschuldigen. Irgendwie ist das Thema komplett an mir vorbei gegangen. :/ Und danke Traude, dass du dich da so reingehangen hast.

Zu dem was du gesagt hast. Das stimmt. Zum Auslesen der Erweiterungen benötigt man einen gültigen Kontext. Ansonsten funktioniert es nicht. Es sei denn man benutzt Windows, dann bekommt man immer die Softwareimplementation vorgesetzt.

InitOpenGL ist in sofern wichtig, da dort die Methoden wie wglProcAdress und glxGetProcAdress geladen werden. Bzw überhaupt erst mal eine OpenGL Bibliothek geladen wird. Das ist wichtig, da diese Bibliothek für alle anderen OpenGL Funktionen benötigt wird. Ohne diese Bibliothek kann die dglOpenGL keine OpenGL Funktionspointer laden.

ReadExtensions und ReadImplementationProperties benötigen einen aktiven Kontext. Und die laden dann die Funktionspointer bzw analysieren welche Erweiterungen unterstützt werden. ReadOpenGLCore wird im übrigen direkt als erstes in ReadExtensions aufgerufen.

Zu glfw. Also Anhand von dem Header würde ich behaupten, dass die nichts großartiges anderes machen als SDL. Aber das ist auch relativ egal. Für die dglOpenGL ist es nur wichtig, dass irgendwie ein Kontext erstellt und aktiviert wurde. Unter Windows geht das mit der hauseigenen Methode aber ob der Kontext von SDL oder glfw erstellt wurde ist egal. Wie häufig die OpenGL DLL geladen wurde bzw wie oft die Funktionspointer erfragt werden spielt auch keine Rolle. In meiner TextSuite gehe ich immer her und lade OpenGL DLL und die Pointer selber. Das ist absolut kein Problem. Nicht mal wenn man die TextSuite selber als DLL einbindet. Das Einzige was passieren könnte ist, dass es etwas länger dauert, wenn 20 Stellen die Pointer laden wollen. Aber glfw wird wohl auch nur eine Hand voll Funktionen brauchen. Da ist die dglOpenGL schon deutlich größer.

Der Code von Traude entspreicht schon genau dem wie er sein sollte. Wobei unter mac die ganzen Methoden der dglOpenGL auskommentiert werden. Was dazu führt, dass die Funktionspointer nicht geladen würden. Also ich denke, wenn man das {$IFNDEF DARWIN} und {$ENDIF} entfernt, dann sollte es so funktionieren. Das InitOpenGL muss dabei auch nicht vor glfwInit stehen. Wichtig ist nur, dass InitOpenGL als erste Methode von der dglOpenGL aufgerufen wurde.


Linux und Developer Bibliotheken. Also wenn ich das richtig mitbekommen habe, dann werden die libGL.so nur dann erstellt, wenn man die Developerversionen der Bibliotheken installiert hat. Ansonsten muss man die libGL.so.1 benutzen. Zu mal die libGL.so sowieso nur ein Link auf die libGL.so.1 ist. Allerdings so wirklich richtig erschlossen hat sich mir dieses System auch noch nicht.


Finde ich allerdings auch interessant. Denn 64 Bit werden eigentlich noch gar nicht richtig unterstützt. Wobei es unter Linux vielleicht doch klappen könnte. Von daher behaupte ich jetzt einfach mal, dass es am noch nicht erstellten Kontext lag. Was 64 Bit angeht. Da sollte man vorsicht walten lassen. Da wird sich aber in der baldigen nächsten Version definitv was tun. Genauso auch bei glx.

Da bin ich aber gespannt, besonders was Du in Bezug auf glx vorhast. *neugierig ist*