OpenGL Extensions

[MarianSchedenig]

Vielleicht bin ich ja einfach zu blöd....aber ich komme mit den OpenGL-Extensions einfach nicht ganz zurecht.

Muß man denn noch irgendwas anderes tun, als die Funktionsadressen abzufragen, bevor man eine Extension verwenden darf?

Zb habe ich gerade zwei ganze Tage mit der Suche nach einem Bug verbracht, am Ende hat sich herausgestellt, daß unter Windows glptrMultTransposeMatrixfARB beim x-ten Aufruf plötzlich abstürzt. Früher nie ein Problem gewesen, und in Linux sowieso nicht (in Linux bräucht ich nicht mal eine Extension dafür, aber Windows packt ja OpenGL >1.1 nicht so ohne weiteres...)

So initialisiere ich die Extension bei Programmstart:


if(!(glMultTransposeMatrixfARB=(glMultTransposeMat rixfARB_t)SDL_GL_GetProcAddress("glMultTransposeMatrixfARB")))
{
throw std::string("glMultTransposeMatrixfARB not found - wrong OpenGL version?");
}
else
{
debug::info(dbgDdd,"glMultTransposeMatrixfARB extension...available.");
}


Und folgender Aufruf hat das Problem verursacht:

glMultTransposeMatrixfARB(&(itr2->viewMatrix.m[0][0]));

Wobei besagte viewMatrix völlig OK ist. m ist dabei definiert als GLfloat[4][4].

Folgender Ersatzaufruf geht einwandfrei:

Matrix3D matrix=itr2->viewMatrix.transpose();
glMultMatrixf(&(matrix.m[0][0]));

Eine Testausgabe vor dem glMultTransposeMatrixfARB hat auch gezeigt, daß der Pointer noch derselbe war wie bei Programmstart. Die GL-Einsprungspunkte können sich doch nicht mitten im Programm ändern, oder??


Und eine andere, auch Extension-bezogene Frage:

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL _CLAMP_TO_EDGE);

...will sich in Windows nicht compilieren lassen. Nicht überraschend, GL_CLAMP_TO_EDGE ist ja auch kein GL 1.1-Feature....nur wie kriege ich Windows dazu, das zu verwenden? Für eine symbolische Konstante kann ich ja nicht so einfach einen Einsprungspunkt erfragen...

:confused:

[bimbo]

...will sich in Windows nicht compilieren lassen. Nicht überraschend, GL_CLAMP_TO_EDGE ist ja auch kein GL 1.1-Feature....nur wie kriege ich Windows dazu, das zu verwenden? Für eine symbolische Konstante kann ich ja nicht so einfach einen Einsprungspunkt erfragen...

:confused:

ist zwar net ganz die feine aber ich habs mir einfach selber definiert:

#define GL_CLAMP_TO_EDGE 0x812F

[Uebungsleitung]

Warum verwendet ihr nicht, wie auf der Software-Page empfohlen, die glew-Library?

Michael Wimmer

[MarianSchedenig]

ist zwar net ganz die feine aber ich habs mir einfach selber definiert:

#define GL_CLAMP_TO_EDGE 0x812F

Ist natürlich eine Möglichkeit...aber das wollte ich eigentlich vermeiden, ist mir eher unheimlich. :)

Warum verwendet ihr nicht, wie auf der Software-Page empfohlen, die glew-Library?

Hatten wir zuerst vor. Ich weiß nicht mehr genau, warum wir das dann wieder aufgegeben haben...wahrscheinlich hat sie entweder unter Windows Probleme mit mingw gemacht, oder wollte nicht mit SDL zusammenarbeiten.

Zumindest hatten wir sie für ca. 10 Minuten drin und haben dann beschlossen, sie wieder zu entfernen. Aus welchem Grund auch immer, damals haben wir das jedenfalls für sinnvoll gehalten.

:)

[ChrisChiu]

Vielleicht bin ich ja einfach zu blöd....aber ich komme mit den OpenGL-Extensions einfach nicht ganz zurecht.

Muß man denn noch irgendwas anderes tun, als die Funktionsadressen abzufragen, bevor man eine Extension verwenden darf?

Zb habe ich gerade zwei ganze Tage mit der Suche nach einem Bug verbracht, am Ende hat sich herausgestellt, daß unter Windows glptrMultTransposeMatrixfARB beim x-ten Aufruf plötzlich abstürzt. Früher nie ein Problem gewesen, und in Linux sowieso nicht (in Linux bräucht ich nicht mal eine Extension dafür, aber Windows packt ja OpenGL >1.1 nicht so ohne weiteres...)

So initialisiere ich die Extension bei Programmstart:


if(!(glMultTransposeMatrixfARB=(glMultTransposeMat rixfARB_t)SDL_GL_GetProcAddress("glMultTransposeMatrixfARB")))
{
throw std::string("glMultTransposeMatrixfARB not found - wrong OpenGL version?");
}
else
{
debug::info(dbgDdd,"glMultTransposeMatrixfARB extension...available.");
}


Und folgender Aufruf hat das Problem verursacht:

glMultTransposeMatrixfARB(&(itr2->viewMatrix.m[0][0]));

Wobei besagte viewMatrix völlig OK ist. m ist dabei definiert als GLfloat[4][4].

Folgender Ersatzaufruf geht einwandfrei:

Matrix3D matrix=itr2->viewMatrix.transpose();
glMultMatrixf(&(matrix.m[0][0]));

Eine Testausgabe vor dem glMultTransposeMatrixfARB hat auch gezeigt, daß der Pointer noch derselbe war wie bei Programmstart. Die GL-Einsprungspunkte können sich doch nicht mitten im Programm ändern, oder??


Und eine andere, auch Extension-bezogene Frage:

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S,GL _CLAMP_TO_EDGE);

...will sich in Windows nicht compilieren lassen. Nicht überraschend, GL_CLAMP_TO_EDGE ist ja auch kein GL 1.1-Feature....nur wie kriege ich Windows dazu, das zu verwenden? Für eine symbolische Konstante kann ich ja nicht so einfach einen Einsprungspunkt erfragen...

:confused:

Eine aktuelle glext.h holen und #include'n. Da sind alle diese Konstanten die > Core 1.2 sind drin, auch GL_CLAMP_TO_EDGE.


Wegen deines Funktionspointerproblems... wo initialisierst du die Pointer (kann es sein, dass die initialisierung irgendwo im Laufe des Programms nochmal aufgerufen wird, und damit du dann den Funktionspointer wieder zurücksetzt vom eigentlichen Einsprungpunkt? Und initialisierst du die auf 0 (bzw. NULL)?

glMultTransposeMatrixfARB=(glMultTransposeMatrixfA RB_t)SDL_GL_GetProcAddress("glMultTransposeMatrixfARB")

Was ist dieses glMultTransposeMatrixfARB_t? Selbst definierter Funktionstyp?

In glext.h hättest du den Typ "PFNGLMULTTRANSPOSEMATRIXFARBPROC", den du gleich verwenden könntest:

PFNGLMULTTRANSPOSEMATRIXFARBPROC glMultTransposeMatrixfARB = NULL;

glMultTransposeMatrixfARB = (PFNGLMULTTRANSPOSEMATRIXFARBPROC) SDL_GL_GetProcAddress("glMultTransposeMatrixfARB");

if (!glMultTransposeMatrixfARB)
usw.

[MarianSchedenig]

Eine aktuelle glext.h holen und #include'n. Da sind alle diese Konstanten die > Core 1.2 sind drin, auch GL_CLAMP_TO_EDGE.

Hmm. Hatte mir eingebildet, ich hätte das schon probiert...aber in dem Punkt trau' ich mir ehrlich gesagt selbst nicht mehr. ;) Werd ich versuchen, danke. (Wahrscheinlich hab ich's irgendwann um 5:00 in der Früh im falschen File includet...)

Wegen deines Funktionspointerproblems... wo initialisierst du die Pointer

Programmstart.

(kann es sein, dass die initialisierung irgendwo im Laufe des Programms nochmal aufgerufen wird, und damit du dann den Funktionspointer wieder zurücksetzt vom eigentlichen Einsprungpunkt?

Definitiv nicht. Wird nur 1x aufgerufen, hab auch Debug-Ausgaben drin, die nur 1x auftauchen. Und ich gebe mir ja den Pointer auch vor jedem Aufruf aus - mein Pointer ändert sich nicht, aber irgendwann crasht der Aufruf - desselben Pointers - trotzdem.

Und initialisierst du die auf 0 (bzw. NULL)?

Wenn das Ermitteln des Pointers fehlschlägt, wird er auf 0 initialisiert (aber das Programm auch mit einer Fehlermeldung abgebrochen).


Was ist dieses glMultTransposeMatrixfARB_t? Selbst definierter Funktionstyp?

In glext.h hättest du den Typ "PFNGLMULTTRANSPOSEMATRIXFARBPROC", den du gleich verwenden könntest:

PFNGLMULTTRANSPOSEMATRIXFARBPROC glMultTransposeMatrixfARB = NULL;

Ah, gut.

glMultTransposeMatrixfARB = (PFNGLMULTTRANSPOSEMATRIXFARBPROC) SDL_GL_GetProcAddress("glMultTransposeMatrixfARB");

if (!glMultTransposeMatrixfARB)
usw.

Mhm. Trotzdem, ich versteh den Grund unserer Crashes nicht. Dieser eine Aufruf macht definitiv den Fehler....Pointerfehler woanders im Programm kann's eigentlich kaum sein, denn jede Änderung, die diesen Aufruf umgehen, funktionieren.

Wir haben aber die glMultTransposeMatrixfARB auch die letzten Wochen lang verwendet (auch in der Abgabeversion) - ohne Probleme. Erst vor ein paar Tagen plötzlich.

:confused:

[ChrisChiu]

Hmm. Hatte mir eingebildet, ich hätte das schon probiert...aber in dem Punkt trau' ich mir ehrlich gesagt selbst nicht mehr. ;) Werd ich versuchen, danke. (Wahrscheinlich hab ich's irgendwann um 5:00 in der Früh im falschen File includet...)



Programmstart.



Definitiv nicht. Wird nur 1x aufgerufen, hab auch Debug-Ausgaben drin, die nur 1x auftauchen. Und ich gebe mir ja den Pointer auch vor jedem Aufruf aus - mein Pointer ändert sich nicht, aber irgendwann crasht der Aufruf - desselben Pointers - trotzdem.



Wenn das Ermitteln des Pointers fehlschlägt, wird er auf 0 initialisiert (aber das Programm auch mit einer Fehlermeldung abgebrochen).



Ah, gut.



Mhm. Trotzdem, ich versteh den Grund unserer Crashes nicht. Dieser eine Aufruf macht definitiv den Fehler....Pointerfehler woanders im Programm kann's eigentlich kaum sein, denn jede Änderung, die diesen Aufruf umgehen, funktionieren.

Wir haben aber die glMultTransposeMatrixfARB auch die letzten Wochen lang verwendet (auch in der Abgabeversion) - ohne Probleme. Erst vor ein paar Tagen plötzlich.

:confused:

Bei solch seltsamen Verhalten tippe ich immer auf Memory Leaks bzw. Out-of-Bounds-Array/Pointer-Zugriffe.

Vielleicht überschreibt ihr irgendwo etwas, was ihr nicht überschreiben solltet (außerhalb eines Arrays), und überschreibt damit zufälligerweise den Funktionspointer.

[MarianSchedenig]

Hätt ich mir ja auch gedacht. Aber mit dem normalen glMultMatrixf-Aufruf geht's ja, und der ARB-Pointer ist auch direkt vor dem Aufruf noch derselbe...seltsames Verhalten hat sich bislang ohne den ARB-Aufruf schlicht und einfach nicht reproduzieren lassen.

[MarianSchedenig]

Hmm. Vielleicht haben wir ja wirklich irgendwo einen "bösen" Pointer... OpenAL führt sich ein bissl komisch auf, und die Änderungen von einem Kollegen bringen das ganze Programm zum Absturz (laut seinen Aussagen hat er im neuen Code keinen Pointerfehler).

Gibt's denn ein Tool, mit dem man sowas halbwegs gut finden kann? Manuelles Durchsuchen wird bei fast 40.000 Codezeilen ein bissl schwierig. ;)

[grimreaper]

Hmm. Vielleicht haben wir ja wirklich irgendwo einen "bösen" Pointer... unter windows gibts da z.b. int _heapchk(void); damit kann man relativ schnell eingrenzen und fehler finden, wenn man irgendwie den heap beleidigt.
das problem ist da ja meistens, daß der fehler/crash nicht beim echten fehler auftritt sondern viel später...
also obige funktion hat mir schon des öfteren mit speicherproblemen geholfen.


OpenAL führt sich ein bissl komisch auf, und die Änderungen von einem Kollegen bringen das ganze Programm zum Absturz (laut seinen Aussagen hat er im neuen Code keinen Pointerfehler).wie gesagt,.. vielleicht ist der heap schon vorher hin.

Manuelles Durchsuchen wird bei fast 40.000 Codezeilen ein bissl schwierig. ;)müssen wir da nicht alle mal durch? :tongue1:

[MarianSchedenig]

unter windows gibts da z.b. int _heapchk(void); damit kann man relativ schnell eingrenzen und fehler finden, wenn man irgendwie den heap beleidigt.

Danke. Werd das mal probieren, wenn der Windows-Rechner wieder rennt (oder meine Windows-Kollegen drauf ansetzen).

(Kennst Du evtl. noch was vergleichbares für Linux? Das einzige Speichertestprogramm, das ich bisher gefunden hab, ist dieses valgrind...und entweder müllen wir den Speicher schon in den ersten paar Millisekunden gigabyteweise zu, oder das Ding hat was gegen OpenGL :p )

das problem ist da ja meistens, daß der fehler/crash nicht beim echten fehler auftritt sondern viel später...

Was bei uns der Fall sein dürfte, denn Debugging an den Fehlerstellen hat bestenfalls Verwirrung gebracht.

müssen wir da nicht alle mal durch? :tongue1:

Ja, aber bitte nicht 4 Wochen vor der Abgabe, wenn noch so viel zu tun ist.... (ja, ich weiß, wann denn sonst - blöder Murphy ;))

[grimreaper]

(Kennst Du evtl. noch was vergleichbares für Linux?nope sry,... von der linux-api weiß ich soviel wie von der landwirtschaft in singapur ;)

Was bei uns der Fall sein dürfte, denn Debugging an den Fehlerstellen hat bestenfalls Verwirrung gebracht.yup,.. das ists leider,.. debugging ist zwar nett, aber wenns um speicher-probleme geht hilfts fast nix ;(

Ja, aber bitte nicht 4 Wochen vor der Abgabe, wenn noch so viel zu tun ist.... (ja, ich weiß, wann denn sonst - blöder Murphy ;))ach wo,.. murphy beginnt dann langsam 4 tage vor der abgabe zuzuschlagen ;]