OpenGL + Extensions

[che g]

Also, dass ich das System richtig verstehe:

OpenGL definiert in jeder Version eine bestimmte Anzahl von 'Core functions' die die Hardware/der treiber unterstützen muss um das Prädikat 'OpenGL 1.x compliant' zu erlangen. Darüber hinaus gibt es Extensions. Während die Core functions immer und überall verwendbar sind müssen die Extensions zuerst geladen (wglgetProcAdress()) werden damit man sie nutzen kann.

Multitexturing (glActiveTexture(), glMultiTexCoord*()...) ist seit OpenGL 1.2.1 Bestandteil der Core functions. Ich müsste also mit meiner R9500PRO die oben genannte Funktionen ohne weiteres nutzen können. Kann ich aber nicht:

error C2065: 'glActiveTexture' : undeclared identifier
error C2065: 'glMultiTexCoord2f' : undeclared identifier


??? Was mache ich falsch?

MfG

[liquid]

afaik muss man unter Windows wegen dieser dummen OGL-1.1 Geschichte alles oberhalb von 1.1 über GetProcAdress() holen, erst dann sind 1.2.1 Core-Funktionen nutzbar.

cya
liquid

[che g]

Versteh ich nicht ganz...
Wenn ich alles was über 1.1 hinausgeht selbst laden muss, dann habe ich genau nix davon dass der Treiber mir 1.3 meldet, ich kann die 1.3 Core functions ja doch nicht nutzen...

[liquid]

Warum kannst die net benutzen? Lad die einfach über GetProcAdress() (wie ich schon gesagt habe) und benutz sie. Die Version die der Treiber ausspuckt macht nur eine Aussage darüber welche Version der Treiber selber hat. Nur solange alles noch über dieses komische Windows OGL Interface ablaufen lässt, ist man quasi an Version 1.1 gebunden und da sind nunmal alles oberhalb von 1.1 Extensions.

cya
liquid

[che g]

Ich wollte mir doch das ganze extension laden sparen.

Wenn mein Treiber sagt '1.3 vorhanden' dann möchte ich gefälligst auch 1.3 nutzen. Ohne Extension-laden-schnickschnack. Punkt. ;)

MfG

[ScottManDeath]

dann nimm doch GLEW (http://glew.sourceforge.net): includen, lib dazu, eine init funktion aufrufen und das wars, kostet 15 min beim ersten mal

[che g]

Ein paar Fragen zum glext-Header:

typedef void (APIENTRY * PFNGLACTIVETEXTUREPROC) (GLenum texture);
typedef void (APIENTRY * PFNGLCLIENTACTIVETEXTUREPROC) (GLenum texture);
typedef void (APIENTRY * PFNGLMULTITEXCOORD1DPROC) (GLenum target, GLdouble s);
typedef void (APIENTRY * PFNGLMULTITEXCOORD1DVPROC) (GLenum target, const GLdouble *v);
typedef void (APIENTRY * PFNGLMULTITEXCOORD1FPROC) (GLenum target, GLfloat s);

opengl.org meint dazu:

'First, declare function prototype typedefs that match the extension’s entry points.'
Hier werden also die Function prototypes deklariert.

Wozu ist dann das gut:

GLAPI void APIENTRY glActiveTexture (GLenum);
GLAPI void APIENTRY glClientActiveTexture (GLenum);
GLAPI void APIENTRY glMultiTexCoord1d (GLenum, GLdouble);
GLAPI void APIENTRY glMultiTexCoord1dv (GLenum, const GLdouble *);
GLAPI void APIENTRY glMultiTexCoord1f (GLenum, GLfloat);
GLAPI void APIENTRY glMultiTexCoord1fv (GLenum, const GLfloat *);


???

MfG

[ScottManDeath]

typedef void (APIENTRY * PFNGLACTIVETEXTUREPROC) (GLenum texture);

zuerst wird damit ein typ "zeiger auf funktion"
deklariert, also die parameter/rückgabtyp der funktionen auf die der zeiger zeigen kann

PFNGLACTIVETEXTUREPROC glActiveTexture;

eine variable vom typ zeiger auf funktion anlegen und

glActiveTexture = (PFNGLACTIVETEXTUREPROC) wglGetProcAddress("glActiveTexture");

damit dann die funktionsaddress vom treiber liefern lassen



GLAPI void APIENTRY glActiveTexture (GLenum);


das ist für libs wenn sie diese funktionen statisch exportieren wie es z.b. unter linux möglich ist. dieser ganze teil wird mit #ifdef...#endif eingefasst, so das es eine glext.h gibt die unter win32 mit alter (1.1) gl.h oder unter *nix mit aktueller (1.X) gl.h funktioniert

[che g]

Original geschrieben von ScottManDeath

GLAPI void APIENTRY glActiveTexture (GLenum);


das ist für libs wenn sie diese funktionen statisch exportieren wie es z.b. unter linux möglich ist. dieser ganze teil wird mit #ifdef...#endif eingefasst, so das es eine glext.h gibt die unter win32 mit alter (1.1) gl.h oder unter *nix mit aktueller (1.X) gl.h funktioniert

Aha. Könntest du das "srtatisch exportieren" noch etwas näher ausführen, irgendwie fang ich damit nix an.
Wie nennt man dann das holen der Funktionsadresse mit wgl...? Dynamisch importieren?

MfG

[ScottManDeath]

statisch heisst das der linker beim linken weiss welche funktionen von der bibliothek exportiert werden und wo in der bibliothek sie liegen, d.h. er kennt die addressen der funktionen beim compilieren/linken. und kann sie entsprechend aufrufen.


dynamisch laden wie du gesagt hast mittels wglGetProcAddress (oder für allgemeiner DLL's mit GetProcAddress) , d.h. du gibst dem treiber( oder i.A. DLL) einen funktionsnamen und er guckt ob es diese funktion gibt und liefert eventuell deren addresse.

für details die MSDN fragen:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dynamic_link_libraries.asp

[che g]

thx @ ScottMan

Noch eine Frage: Meldet mein Treiber 1.3 dann, kann ich zum Laden die glxxx() Funktionen verwenden. Meldet er z.B nur 1.1, dann MUSS ich glxxxARB() benutzen. (Oder eben EXT, ATI, was auch immer)

MfG