My opengl version is 4.0 and use glad3.3.
I want to use glTexEnvi(), but only glad4.6 support this function and I can't use it. When I include both glad.h and glew.h, there was an error(error C1189:#error:gl.h included before glew.h).
So how can I use glad.h and glew.h at the same time? or is there another solution to use glTexEnvi()?
Anyone help?
You don't. Glad and GLEW are both OpenGL loaders. Both do the same thing; they provide OpenGL function binding. Use either one or the other.
glTextEnv is a legacy OpenGL function. It is only provided in an compatibility profile OpenGL Context (respectively OpenGL 1.x and 2.x) and OpenGL ES 1.0.
Thus glTexEnv is not available in a core profile context, OpenGL ES 2.0 and OpenGL 3.x.
See OpenGL specification - Khronos OpenGL registry and OpenGL ES Specification - Khronos OpenGL ES Registry
You have to use a compatibility profile OpenGL 3.3 Context. Ensure that the profile type is "compatibility" when you generate the OpenGL loader files, then glTexEnvi is defined.
Glad is a loader generator. You have to specify the OpenGL (ES) version, for your target environment. Glad generates an API, which provides exactly the available instruction set for the specified environment respectively OpenGL (ES) verison. If an instruction does not "exist" in the header file, then it is not supported by the specified version.
In compare GLEW provides all OpenGL functionality is in a single header file. You have to care if a function is supported by the OpenGL context.
I'm a bit confused about when exactly I need to use an OpenGL function loader like GLEW. In general, it seems like you first obtain a window and valid OpenGL context and then attempt to load functions.
Sometimes these functions are referred to as extensions, sometimes they are called core functions as well. It seems like what's loaded and classified as 'core' and 'extension' is platform dependent. Are the functions that are loaded in addition to some base set?
Do you need to load functions in the same way on OpenGL ES platforms as well? Taking a quick look at GLEW, I don't see any explicit support for Open GL ES. Other GL function loader libs do explicitly mention support specifically for ES however (like https://github.com/Dav1dde/glad)
OpenGL functions (core or extension) must be loaded at runtime, dynamically, whenever the function in question is not part of the platforms original OpenGL ABI (application binary interface).
For Windows the ABI covers is OpenGL-1.1
For Linux the ABI covers OpenGL-1.2 (there's no official OpenGL ABI for other *nixes, but they usually require OpenGL-1.2 as well)
For MacOS X the OpenGL version available and with it the ABI is defined by the OS version.
This leads to the following rules:
In Windows you're going to need a function loader for pretty much everything, except single textured, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In Linux you're going to need a function loader for pretty much everything, except basic multitextured with just the basic texenv modes, shaderless, fixed function drawing; it may be possible to load further functionality, but this is not a given.
In MacOS X you don't need a function loader at all, but the OpenGL features you can use are strictly determined by the OS version, either you have it, or you don't.
The difference between core OpenGL functions and extensions is, that core functions are found in the OpenGL specification, while extensions are functionality that may or may be not available in addition to what the OpenGL version available provides.
Both extensions and newer version core functions are loaded through the same mechanism.
datenwolf's answer is great, but I wanted to clarify something you said in the first bullet point of your question.
Core and extension status is not platform-dependent or even mutually exclusive.
Core means that some feature was introduced in a certain version of OpenGL. There are core functions, which are things that are guaranteed to exist in version X.Y and there are even core extensions, which are extensions that were introduced alongside version X.Y. Core extensions provide the same functions, types, enums, etc. as the core feature only in an extension form that does not require a specific version.
Framebuffer Objects went core in OpenGL 3.0, and are slightly less restrictive than the EXT extension (GL_EXT_framebuffer_object) that predates OpenGL 3.0. However, it is not necessary to have an OpenGL 3.0 implementation to have access to the core version of FBOs - an OpenGL 2.1 implementation might offer the core functionality.
In the extension specification for GL_ARB_framebuffer_object, you will find:
Issues
(8) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?
RESOLVED: Unlike most ARB extensions, this is a strict subset of
functionality already approved in OpenGL 3.0. This extension
exists only to support that functionality on older hardware that
cannot implement a full OpenGL 3.0 driver. Since there are no
possible behavior changes between the ARB extension and core
features, source code compatibility is improved by not using
suffixes on the extension.
That is the first mention of a core extension that I can recall, but it is not the last. Since then many ARB extensions have been created that "backport" (if you will) core functionality from a higher version.
Here is some sample output gathered by parsing gl.xml for another core extension:
>> Command: void glBufferStorage (GLenum target, GLsizeiptr size, const void *
data, GLbitfield flags)
* Provided by GL_ARB_buffer_storage (gl|glcore)
* Core in GL_VERSION_4_4 ( gl 4.4)
It is core in 4.4 (guaranteed to exist in a 4.4 implementation), but because the extension that provides it is glcore, this core function may be available in older implementations if the core extension is available.
The simple piece of software I wrote to parse gl.xml for this information can be found here if you are interested.
Function loaders are only needed on Windows and Linux. Here's a quick overview of how you build for various OpenGL versions on different platforms.
Windows
The Windows development tools only contain headers for OpenGL 1.1. The conspiracy theorists would probably claim that Microsoft is not interested in making the use of OpenGL easy because it wants developers to use a proprietary API instead.
For anything beyond 1.1, you need to load the entry points dynamically by calling wglGetProcAddress(). Libraries like GLEW provide header files for higher OpenGL versions, and encapsulate the logic for loading the entry points.
Linux
I haven't done OpenGL programming on Linux. From what I hear, it requires function loading similar to Windows. I'll defer to #datenwolf's answer for the details.
Mac OS
Mac OS supports two main OpenGL feature sets:
OpenGL 2.1 with legacy features. This is used by including <OpenGL/gl.h>.
OpenGL 3.x and higher, Core Profile only. Used by including <OpenGL/gl3.h>.
In both cases, you don't need any dynamic function loading. The header files contain all the declarations/definitions for the maximum version that can be supported, and the framework you link against (using -framework OpenGL) resolves the function names.
The maximum version you can use at build time is determined by the platform SDK you build against. By default, this is he platform SDK that matches the OS of your build machine. But you can change it by using the -isysroot build option.
At runtime, the machine has to run at least the OS matching the platform SDK used at build time, and you can only use features up to the version supported by the GPU. You can get an overview of what version is supported on which hardware on:
https://developer.apple.com/opengl/capabilities/
http://support.apple.com/en-us/HT202823
Android, NDK
With native code on Android, you choose the OpenGL version while setting up the context and surface. Your code then includes the desired header (like <GLES2/gl2.h> or <GLES3/gl3.h>) and links against the matching libraries. There is no dynamic function loading needed.
If the target device does not support the version you are trying to use, the context creation will fail. You can have an entry in the manifest that prevents the app from being installed on devices that will not support the required ES version.
Android, Java
This is very similar to the NDK case. The desired version is specified during setup, e.g. while creating a GLSurfaceView.
The GLES20 class contains the definitions for ES 2.0. GLES30 derives from GLES20, and adds the additional definitions for ES 3.0.
iOS
Not surprisingly, this is very similar to Mac OS. You include the header file that matches the desired OpenGL ES version (e.g. <OpenGLES/ES3/gl.h>), link against the framework, and you're all done.
Also matching Mac OS, the maximum version you can build against is determined by the platform SDK version you choose. Devices you want to run on then have to use at least the OS version that matches this platform SDK version, and support the OpenGL ES version you are using.
One main difference is obviously that you cross compile the app on a Mac. iOS uses a different set of platform SDKs with different headers and frameworks, but the overall process is pretty much the same as building for Mac OS.
I am trying to get an OpenGL/glew program from a template made by my uni lecturer work. He has added this code to his program:
if(!GLEW_VERSION_3_1) {
std::cerr << "Driver does not support OpenGL 3.1" << std::endl;
return 1;
}
This prints the error on my mac. After some experimenting, I have found out that my mac is actually running OpenGL (2.1 INTEL-8.28.30). I have worked my way around this using a nasty #ifndef APPLE before that part of the code, but I cannot do this in the long term.
Is there any way in which I can upgrade to 3.1?
The issue is related to the concept of core and compatibility contexts in OpenGL, and Apple's implementation. You need to make sure the application requests a core profile OpenGL context.
Apple support a compatibility OpenGL context (with support for all of the old deprecated features) up until a maximum of OpenGL 2.1 (plus several extensions).
Apple support a core OpenGL context (with old deprecated features removed) up until a maximum of OpenGL 4.1 (dependent on hardware support, 3.3 on older hardware) with OSX Mavericks. If you download a program called OpenGL Extension Viewer, you can see what you've got available.
When your program creates an OpenGL context, it gets compatibility by default (to avoid breaking old programs). You need to specifically flag that you want a core profile. The way to do this will depend what windowing library you're using. If you happen to be using SDL2, there's just an extra flag to set when creating the context. If using Apple GL directly, you'd need to check their documentation.
See: http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts
Note: I notice you're using GLEW. I encountered issues with GLEW and core contexts in the past. This is because it was requesting extension strings using a method that's deprecated (and therefore fails in a core context). It made it look like no extensions were supported. If this happens, refer to the GLEW website, there was an experimental option you could pass to its init to make it work.
I'm using GLFW and Netbeans to develop in C++. I'm able to render with immediate mode functions no problem. However, when I try to use core profile functions I get errors like this:
error: ‘glCreateShader’ was not declared in this scope
I get one of these errors for each core profile function I try. I did some research and found that GLFW doesn't provide any gl headers and just #includes the headers found on my system (at /usr/include/GL/).
Presumably this means that the gl.h and related files found here only contain the old style OpenGL API. I can't make sense of the hex code, but the gl.h file #defines GL_VERSION as 0x1F02.
If I perform this command in terminal: glxinfo | grep -i opengl it assures me that my OpenGL version string is "4.2.0 NVIDIA 304.88" -- Although I think that's reflected in the driver, unrelated to the gl.h file. Running this line in C++ code in my application yields the same string: printf("%s\n", glGetString(GL_VERSION)); For the same reason, no doubt.
Where can I source the appropriate OpenGL header files for OpenGL 3+ development on Ubuntu 13.04 x64?
I have installed these packages as suggested by most tutorials (to no avail): xorg-dev libglu1-mesa-dev
glCreateShader (...) is an OpenGL 2.0 function.
Short of OS X, I cannot think of any platforms that ship with OpenGL 2.0 without requiring runtime extension. On Microsoft Windows, you are guaranteed the full feature set of OpenGL 1.1 and anything beyond that requires calls to wglGetProcAddress (...) to load the function entry-points for the rest of the OpenGL API. The situation is the same on Linux, though it is more difficult to define what the "minimum" feature set is. In any case, to use glCreateShader (...) you are going to have to call glXGetProcAddress (...) in order to get the entry-point from the driver.
Libraries like GLEW will make your life easier by loading the entry-point for every function for each extension and core version of OpenGL your driver supports, on Ubuntu there should even be a package you can install that contains GLEW. Nevertheless, see the official project site for more details on actually using GLEW.
I've read around that there is a lot of deprecation going on with OpenGL. I've heard this has to do with the implementation of shaders. Are there any libraries that are affected by this deprecation?
seems to suggest SFML, GLFW, and SDL as up to date libraries.
Do other libraries such as glew or glut have problems with the deprecation?
GLUT is the utility library which contains helpful methods mostly related to GUI. GLUT is outdated for something like 10 years already so it can't be used with the new (programmable) pipeline. From what I know it supports up to GL 3.1 inclusive only. The project which replaces GLUT is FREE GLUT which is up to date and can be used both with old and new OpenGL versions. Glew is the lib that exposes the GL API for windows users. It has both deprecated and current functionality. It is up to you which to use as it mostly depends on GL version and profile type you choose. If you use compatability profile for example in OpenGL 4.0 version then you can use mix of deprecated and 4.0 API specific functionality. But if you select Core profile then using deprecated methods will not work.