Ich arbeite gerade an einem GL-Projekt mit Eclipse und CDT3.0. Als Compiler kommt der GCC zum einsatz.

Alles lief gut, bis ich Multitexturing einbauen wollte. Der Compiler sagt, er kenne die Funktion glActiveTexture und glMultiTexCoord nicht.
Ich habe den glext.h eingebunden. Dieser enthält ja (zumindest unter Windows) diese Funktionen.
Wenn ich per Ctrl+Click auf einen der beiden Namen klicke, meldet mir Eclipse, dass es die Funktionen nicht finden könne. Wenn ich z.B. eine der Konstanten (GL_TEXTURE1) anklicke, komme ich in dem Header raus, welcher auch die Funktionen beinhaltet.

Ich vermute nun folgendes:
Der Compilerschalter GL_GLEXT_PROTOTYPES schien das zu verhindern. Den hab ich jetzt aber programmseitig auf true gesetzt. Trotzdem nichts.

Ich komm hier nicht weiter. Ich kenn mich auch mit dem gcc nicht so übermäßig aus, um nachzuvollziehen, wieso er Funktionen aus der glext.h nicht einbindet, die Constanten aber schon. Wenn ihr mir da helfen könntet wäre das super, es ist nämlich verhältnismäßig wichtig, das ich das zum laufen bekomme.

PS: Kurzer ausschnitt aus der glext.h

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

Vielleicht ist es an der Zeit, dass die Skeptiker unter uns den Header vechseln.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

wenns schnell gehen soll benutz ich immer http://elf-stone.com/glee.php die GLee Lib die sich um das ganze extensions laden kümmert und die funktionspointer klar macht.
hab aber keine ahnung von eclipse und gcc, benutz M$ VS. müsste aber gehen, oder ?!

_________________
www.extrawurst.org

Koennte mir denken das du vielleicht den entsprechenden Namespace nicht eingebunden hast. Ist es dass?

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Oder muß man da noch extra eine LIB Datei mit hinzulinken? Oft ist es mit dem Einbinden von dem Header bei C++ ja nicht getan.

Ich hab die OpenGL32 und GLU32 Libs eingelinkt.

Einen Namespace gibt es für die extensions auch nicht.

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

Wäre es möglich, dass du glext.h öfter als einmal includierst und das GL_GLEXT_PROTOTYPES beim ersten mal nicht gesetzt ist? Also beispielsweise:

foo.h
#include "glext.h"

bar.cpp oder bar.h
#include "foo.h"
#define GL_GLEXT_PROTOTYPES
#include "glext.h"

oder sowas in der Art? Um derartige Fehler auszuschließen ist es meistens eine gute Idee sowas als Umgebungsvariable in der Entwicklungsumgebung bzw. beim compilieren zu setzen.

War zwar der Fall, aber nachdem ich das geändert habe bleibt der Fehler.

Das "#define GL_GLEXT_PROTOTYPES 1" steht in der *.cpp welche auch die main() enthält, und dort direkt vor dem Aufruf von "#include <GL/glext.h>".

Ich bin mir auch nicht sicher ob man diese "Prototypen" überhaupt benötigt, da anscheinend nachher die Einsprungadressen (?) per APIENTRY angegeben werden.

Programmiert denn hier keiner mit C++ und dem GCC? Wir haben doch ne Menge C++ler mittlerweile hier.

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

Bei Nehe (hab mir die übersetzung bei Joachim Rhode angeguckt) binden die die Funktionen selber. Muss man das machen? Macht das nicht der Header

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

Ist aber noch lange kein Grund das es auch in den anderen .cpp's so sein muss :-). Bei C wird jede .cpp einzeln kompiliert und demnach können Funktionen in einer .cpp vorhanden sein, in einer anderen nicht.

Das APIENTRY ist als extern definiert wenn ich mich nicht irre und tut hier eher wenig zur Sache.

Wenn bereits der Compilier einen Fehler ausspuckt, dann ist im Header was falsch. Wenn der Linker einen Fehler ausspuckt, dann ist die Bibliothek die du verwendest mies oder du musst noch ein bisschen was coden. Wenn er zur Laufzeit sagt: "Ausnahmefehler blablabla" dann hast du zwar einen Pointer auf die entsprechende Funktion, dieser ist jedoch leider NULL oder ein anderes Nirvana.

Ok..Ich hab jetzt das define direkt an den Anfang des Headers geschrieben.

Compilieren tuts. Nur nicht Linken.

Hier mal die Meldung:


Könnt ihr was damit anfangen?

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

APIENTRY steht für stdcall, aber wie gesagt, tut hier nichts zur Sache.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

Ok, hab mir das glext Zeugs noch mal näher angesehen. Also wie's aussieht ist das GL_GLEXT_PROTOTYPES nur ratsam wenn du eine Bibliothek hast die die entsprechenden Extensions (direkt) unterstützt. D.h. du musst dir entweder selber noch was schreiben im Sinne von:

OGL_Extensions.h:
extern PFNGLACTIVETEXTUREPROC glActiveTexture;

OGL_Extensions.cpp:
PFNGLACTIVETEXTUREPROC glActiveTexture;
und irgendwo ein
glActiveTexture = (PFNGLACTIVETEXTUREPROC) wglGetProcAddress("glActiveTextureARB");

Oder aber du nimmst dir das SDK von http://oss.sgi.com/projects/ogl-sample/sdk.html, oder etwas anderes in der Art.

meine glext.h stammt aus dem SDK. Irgendwie hab ich sowas befürchtet.

Wieso muss man das denn alles selber amchen? Gibts da nicht einen ähnlich komfortablen Header wie die DGLOpenGL.pas auch für C++? Bei der gl.h und glu.h muss ich auch nix mehr binden...

Wie machst du das denn? Du bist doch C++ler

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

Da oben wurde doch die Rückkonvertierung von dglopengl.pas gepostet.