Ich bin ein wenig verwirrt darüber, wann genau ich einen OpenGL-Funktionslader wie GLEW verwenden muss. Im Allgemeinen scheint es, als ob Sie zuerst ein Fenster und einen gültigen OpenGL-Kontext erhalten und dann versuchen, Funktionen zu laden.
Manchmal werden diese Funktionen als Erweiterungen bezeichnet, manchmal werden sie auch als Kernfunktionen bezeichnet. Es scheint so, als ob das, was als "Kern" und "Erweiterung" geladen und klassifiziert wird, plattformabhängig ist. Sind die Funktionen, die zusätzlich zu einigen Basis-Sets geladen werden?
Müssen Sie Funktionen auf OpenGL ES-Plattformen genauso laden? Bei einem kurzen Blick auf GLEW sehe ich keine explizite Unterstützung für Open GL ES. Andere Loader-Bibliotheken von GL-Funktionen erwähnen explizit die Unterstützung speziell für ES (wie Ссылка )
OpenGL-Funktionen (Kern oder Erweiterung) müssen zur Laufzeit dynamisch geladen werden, wenn die fragliche Funktion nicht Teil der originalen OpenGL-ABI-Anwendung (Anwendung binary ) ist.
Dies führt zu den folgenden Regeln:
Der Unterschied zwischen Kern-OpenGL-Funktionen und -Erweiterungen besteht darin, dass Kernfunktionen in der OpenGL-Spezifikation zu finden sind, während Erweiterungen Funktionen sind, die zusätzlich zu den verfügbaren OpenGL-Versionen verfügbar sind oder nicht verfügbar sind.
Sowohl die Kernfunktionen der Erweiterungen als auch der neueren Versionen werden über denselben Mechanismus geladen.
datenwolfs Antwort ist großartig, aber ich wollte etwas klarstellen, was Sie im ersten Punkt Ihrer Frage gesagt haben.
Core bedeutet, dass ein Feature in einer bestimmten Version von OpenGL eingeführt wurde. Es gibt Kernfunktionen, die in Version X.Y garantiert vorhanden sind, und es gibt sogar Kernerweiterungen, die Erweiterungen sind, die zusammen mit der Version X.Y eingeführt wurden. Core-Erweiterungen bieten die gleichen Funktionen, Typen, Aufzählungen usw. als Kernfunktion nur in einer Erweiterungsform, für die keine bestimmte Version erforderlich ist.
Framebuffer-Objekte haben in OpenGL 3.0 den Kern übernommen und sind etwas weniger restriktiv als die Erweiterung EXT ( GL_EXT_framebuffer_object ) vor OpenGL 3.0. Es ist jedoch nicht notwendig, eine OpenGL 3.0-Implementierung zu haben, um Zugriff auf die Kernversion von FBOs zu haben - eine OpenGL 2.1-Implementierung könnte die Kernfunktionalität bieten.
GL_ARB_framebuffer_object finden Sie: Probleme
(8) Warum haben die neuen Token und Einstiegspunkte in dieser Erweiterung keine? "ARB" -Suffixe wie andere ARB-Erweiterungen?
BEHOBEN : Im Gegensatz zu den meisten ARB-Erweiterungen ist dies eine strikte Untermenge von Funktionalität bereits in OpenGL 3.0 genehmigt. Diese Erweiterung existiert nur, um diese Funktionalität auf älterer Hardware zu unterstützen kann keinen vollständigen OpenGL 3.0-Treiber implementieren. Da es keine gibt Mögliche Verhaltensänderungen zwischen der ARB-Erweiterung und dem Kern Features, Quellcode-Kompatibilität wird verbessert, indem Sie nicht verwenden Suffixe auf der Erweiterung.
Das ist die erste Erwähnung einer Kernverlängerung, an die ich mich erinnern kann, aber sie ist nicht die letzte. Seitdem wurden viele ARB -Erweiterungen erstellt, die die Kernfunktionalität von einer höheren Version "zurückportieren".
gl.xml für eine andere Kern-Erweiterung gesammelt wurde: Es ist Kern in 4.4 (garantiert in einer 4.4-Implementierung vorhanden), aber da die Erweiterung, die es bereitstellt, glcore ist, kann diese Kern -Funktion verfügbar sein in älteren Implementierungen, wenn die Core-Erweiterung verfügbar ist.
Die einfache Software, die ich geschrieben habe, um gl.xml für diese Informationen zu analysieren, finden Sie hier , wenn Sie es sind interessiert.
Funktionslader werden nur unter Windows und Linux benötigt. Hier ist ein kurzer Überblick darüber, wie Sie für verschiedene OpenGL-Versionen auf verschiedenen Plattformen erstellen.
Die Windows-Entwicklungstools enthalten nur Header für OpenGL 1.1. Die Verschwörungstheoretiker würden wahrscheinlich behaupten, dass Microsoft nicht daran interessiert ist, die Verwendung von OpenGL einfach zu machen, da Entwickler stattdessen eine proprietäre API verwenden sollen.
Für alles andere als 1.1 müssen Sie die Einstiegspunkte dynamisch laden, indem Sie wglGetProcAddress() aufrufen. Bibliotheken wie GLEW bieten Header-Dateien für höhere OpenGL-Versionen und kapseln die Logik zum Laden der Einstiegspunkte ein.
Ich habe OpenGL-Programmierung unter Linux nicht gemacht. Von dem, was ich höre, erfordert es Funktion laden ähnlich wie Windows. Ich werde auf @ datenwolf die Antwort für die Details verschieben.
Mac OS unterstützt zwei Hauptfunktionen von OpenGL:
<OpenGL/gl.h> . <OpenGL/gl3.h> eingeschlossen wird. In beiden Fällen benötigen Sie kein dynamisches Laden von Funktionen. Die Headerdateien enthalten alle Deklarationen / Definitionen für die maximale Version, die unterstützt werden kann, und das Framework, mit dem Sie eine Verknüpfung herstellen (mit -framework OpenGL ), löst die Funktionsnamen auf.
Die maximale Version, die Sie zur Build-Zeit verwenden können, wird durch das Plattform-SDK bestimmt, für das Sie erstellen. Standardmäßig ist dies das Plattform-SDK, das mit dem Betriebssystem Ihres Build-Rechners übereinstimmt. Sie können dies jedoch ändern, indem Sie die Option -isysroot build verwenden.
Zur Laufzeit muss die Maschine mindestens das Betriebssystem ausführen, das mit dem zum Zeitpunkt der Erstellung verwendeten Plattform-SDK übereinstimmt, und Sie können nur Funktionen verwenden, die der von der GPU unterstützten Version entsprechen. Sie erhalten einen Überblick darüber, welche Version auf welcher Hardware unterstützt wird:
Mit nativem Code unter Android wählen Sie die OpenGL-Version aus, während Sie den Kontext und die Oberfläche einrichten. Ihr Code enthält dann den gewünschten Header (wie <GLES2/gl2.h> oder <GLES3/gl3.h> ) und Links mit den passenden Bibliotheken. Es ist keine dynamische Funktionsladung erforderlich.
Wenn das Zielgerät die zu verwendende Version nicht unterstützt, schlägt die Kontexterstellung fehl. Sie können einen Eintrag im Manifest haben, der verhindert, dass die App auf Geräten installiert wird, die die erforderliche ES-Version nicht unterstützen.
Dies ist dem NDK-Fall sehr ähnlich. Die gewünschte Version wird während des Setups angegeben, z. beim Erstellen eines GLSurfaceView .
Die Klasse GLES20 enthält die Definitionen für ES 2.0. GLES30 leitet sich von GLES20 ab und fügt die zusätzlichen Definitionen für ES 3.0 hinzu.
Nicht überraschend, das ist Mac OS sehr ähnlich. Sie fügen die Header-Datei ein, die der gewünschten OpenGL ES-Version entspricht (z. B. <OpenGLES/ES3/gl.h> ), verknüpfen mit dem Framework und Sie sind fertig.
Auch für Mac OS gilt, dass die maximale Version, für die Sie ein Build erstellen können, von der Plattform-SDK-Version bestimmt wird, die Sie auswählen. Geräte, auf denen sie ausgeführt werden sollen, müssen mindestens die Betriebssystemversion verwenden, die dieser Plattform-SDK-Version entspricht, und die von Ihnen verwendete OpenGL ES-Version unterstützen.
Ein Hauptunterschied besteht offensichtlich darin, dass Sie die App auf einem Mac kompilieren. iOS verwendet einen anderen Satz von Plattform-SDKs mit unterschiedlichen Headern und Frameworks, aber der Gesamtprozess entspricht weitgehend dem für Mac OS.