Ich mach mir das selber weil ich ohnehin zusätzlich zu den Funktionen noch einen Wrapper um die ganzen OGL Funktionen hab wo ich dann bei Bedarf mit loggen kann, das geht dann gleich in einem da ne neue Extension einzubinden. Vielleicht werd ich beizeiten auch mal umstellen auf was fertiges (zB wenn ich mich dann mit Shadern rum spielen will wär sicher ein guter Zeitpunkt dafür :-) ).

Die glext.h ist aber nur ein Teil des SDKs, soweit ich gesehen hab macht das glprocs.h und .cpp ziemlich genau das was ich oben geschrieben hab, nur halt ein bisschen ... komischer :-). Sind eh Beispiel-Programme auch dabei, sollte also nicht allzu schwer sein das einzubinden.

Is nich wahr !

Iich dachte das wär ein Witz gewesen, und er hätte die *.pas gepostet.

Kann man den Header einfach so verwenden wie unter Delphi? Ich mein, muss ich gl.h, glu.h und die Libs noch einbinden/dazulinken, oder wie läuft das.
Edit: Ist die auch Plattformunabhängig? Ich seh da ein include windows.h ohne ein ifdef win32 ringsrum...? Is zwar jetzt nicht ganz so wichtig, aberfür später vielleicht schon.
Wer pflegt eigentlich diesen Header? Sollte man den mit im Wiki erwähnen (so wie den Header für D3)?

Bin begeistert.

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

Es sollte genaus so verwendet sein, als unter Delphi. Einfach NUR #include "dglopengl.h", dann CreateRenderingContext etc...

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

Und muss ich noch irgendwas dazulinken? OpenGL32.dll, GLU32.dll, etc.?

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

Nein.

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

Hmmm...aber irgendwas muss noch fehlen, da alle OpenGL-Funktionen beim linken eine undefined Reference hervorrufen.

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

Also wenn ich OpenGL standatdmäßig in Visual C++ nutze muss ich das dem Linker sagen: opengl32.lib glu32.lib

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Ich hab die schon dazugelinkt. Geht trotzdem nicht.
Werd wohl oder übel per GetProcAdress die Funktionen Binden müssen. Das nervt!

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

Ok ich bin jetzt zum manuellen aktivieren übergegangen.

In der cpp wo ich Multitexturing benötige habe ich folgendes gemacht



Beim aufruf von glActiveTextureARB bekomme ich einen Segmentation fault. Und zwar weil die Funktionen angeblich noch NULL sind. Wieso? An der Initialisierung kanns ja nun nicht mehr liegen oder?

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

Hast du bereits einen OGL-Konzext zum Zeitpunkt wo der Konstruktor aufgerufen wird? Ansonnsten weiß er ja nicht ob er zB im Software-Modus rendert wo du wahrscheinlich kein Multitexturing hast. Generell ist es meistens eine gute Idee zu prüfen ob der Rückgabewert von wglGetProcAddress != NULL war.

Danke! Das wars. Hab das entsprechend geändert. Super!

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

Also Falsh, hier ist ein OGL Sample mit meinem Header ohne irgendwelche libs dazu zu brauchen. ( Erstellt und kopiliert mit CodeBlocks )

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