Texturen laden für OpenGl (DGLOpenGl)

[t-z]

Nein, im Constructor rufe ich "inherited Create(AOwner);" immer zuerst auf. Im Destructor kommt "inherited Destroy;" ganz an den Schluss.

[Scotty]

Wäre cool, wenn du mal eine einheitliche plattformunabhängige OpenGL-Komponente bauen würdest

Lazarus liefert so etwas schon mit im Paket LazOpenGLContext. Es gibt auch Beispiele, wie das zu benutzen ist inklusive Laden von Bildern respektive Texturen. Dadurch erspart man sich die DGL-Sachen und auch Glu muss dann nicht unbedingt sein. Allerdings geht das noch nicht unter Darwin.

[carli]

Wäre cool, wenn du mal eine einheitliche plattformunabhängige OpenGL-Komponente bauen würdest

Lazarus liefert so etwas schon mit im Paket LazOpenGLContext.

Pakete sind ungünstig, weil man sie erst konfigurieren und einkompilieren muss, oder sehe ich das falsch?
Ich will, dass ein Entwickler das Lazarus-Projekt öffnet, auf den grünen Knopf klickt und das ganze startet. (Oder hast du eine Lösung dafür?)

[Scotty]

Ich glaube, dass auch ohne vorheriges Einbinden der Package erfolgreich kompiliert werden kann. Ansonsten sind aber Pakete genau für diesen Zweck da und du willst die LCL ja auch nicht neu erfinden

[t-z]

Zur Zeit habe ich kein Paket. Das ganze befindet sich allerdings auch im Programmordner. Für eine Designzeitkomponente benötigt man ein Paket.

Nein, ich möchte die LCL sicher nicht neu erfinden. Ohne LCL/VCL ist meine Komponente gar nicht erst lauffähig. Ich möchte für meine Programme eine Funktion nutzen können, die mir die LCL nicht bietet.

Ich benutze den DGL-Header, da er sehr gut (in deutsch) dokumentiert ist und gut gepflegt wird. Daneben ist er vollständig FPC-Kompatibel und er soll nahezu alle Funktionen auch unter Linux unterstützt (noch nicht getestet). Wie es sich mit Mac verhält weiß ich nicht, aber ehrlich gesagt interessiert mich dies aus oben genannten Gründen auch eher wenig.

[MAC]

Komisch.
Seitdem ich zu Win64 gewechselt habe hab ich den gleichen Fehler...
Error: Import libary not found for c...

entweder hat fpc64 da nen problem oder windows, wobei letzteres wahrscheinlicher sit

naja, auf den ersten blick scheint es mit der änderung in {$if not(defined(Win32) or defined(Win64))} zu klapen...

[t-z]

Das liegt vermutlich daran, dass du eine 64-Bit-Anwendung kompilierst. Und da ist "Win32" nicht definiert. {$ifdef Unix} ist aber wirklich einfacher und übersichtlicher. Wie sich das mit MacOS verhält weiß ich nicht - dies ist darin überhaupt nicht berücksichtigt.

Zur Zeit habe ich keine Zeit um an meinem Projekt weiter zu machen, da bei mir Klausuren anstehen.