I queried my opengl version using glGetString(GL_VERSION) and it returned 3.3.0. As far as I know, 3.3 does have the GL_TEXTURE_RECTANGLE flag. However I'm unable to find it in my gl.h header nor does my compiler(VC++) recognize the flag. All my other openGL calls seem to run fine. Any ideas?
Unfortunately, Visual Studio does not ship with up-to-date OpenGL support. Check out GLEW for a solution to this problem.
Related
I am using legacy code that was written for OpenGL 1.1 (from the Windows SDK v7.0A), and uses Glut.
As Glut is not readilty available in the SDK, what version should I download ?
Update:
I tried with Glut 3.7, apparently the latest release (copyright up to 1998 ?), just to see, and it seems to work fine. Anyway, I couldn't find compatibility information anywhere...
You should never use the old GLUT. You should use FreeGLUT, which is backwards compatible with it. And FreeGLUT doesn't have restrictions on which OpenGL version you use (outside of adding support for core profiles and other profile parameters, but those are irrelevant to you).
I am developing a project using OpenGL and I need to use shaders. I have an example project which was given to me but I am struggling to compile it - I get the error: Function glGetUniformLocation cannot be resolved.
I am using Ubuntu 14.04, and the images below show my current graphics driver and OpenGL version as well as a screenshot of eclipse where you can see the problems list and, as I believe, the prototype of the function in glew.h which is included by the project.
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.
Recently I migrated over to SDL from Glut to get more control over the main loop. I've had shadow maps in my application for a while now using calls like bind framebuffer and gen framebuffer. After migrating over to SDL, I get an error for undeclared Identifier for only these calls. I downloaded the SDL off the website today and imported SDL2/SDL.h and SDL2/SDL_opengl.h. When I open the declaration for one of these "missing calls" it gives it to me, in OpenGl/glext.h. I noticed that the SDL OpenGL imports the OpenGL/gl.h which imports glext.h. Is there a file I'm importing wrong? All the other OpenGl calls work in the rest of my program, so I have no idea what the problem is. Any help would be appreciated. Thanks.
EDIT: I was able to delve deeper into glut and was able to come up with this to get it to work:
#pragma comment (lib, "glu32.lib")
#include <OpenGL/glu.h>
Is this ok?
Everything that goes a certain version of OpenGL (Windows: 1.1, Linux 1.2) must be dynamically loaded through the so called extension mechanism. The OpenGL headers and including them are not enough. The typical recommendation is to use a loading library like GLEW or glload to do the tedious work.
It depends on the platform you're using, but glBindFramebuffer<ARB|EXT> (...) is an extension on many. It was integrated into the core of OpenGL 3.0, so if your platform does not guarantee support for OpenGL 3.0 you are probably going to have to use an extension loading library (e.g. GLEW). If your driver provides OpenGL 3.0, you may still have to use the run-time extension mechanism to load the core function glBindFramebuffer (...).
The fact that "glext.h" contains it does not say a whole lot. That header is where prototypes, enumerants / constants and typedefs for parts of OpenGL that are extended at run-time are defined. You still have to setup a function pointer in your software and ask the driver for the address before you can call them - this is what extension loading libraries do in a nutshell.
EDIT1:
No, that is not okay. glBindFramebuffer (...) is part of OpenGL 3.0. Microsoft Windows implements OpenGL 1.1, and GLU should not change this at all. If forcing MSVC to link against GLU fixes unresolved linker errors to an OpenGL 3.0 function something is seriously wrong.
EDIT2:
Judging by the discussion in the comments, you are not only moving from SDL to GLUT, but also from OS X to Win32. On Win32 you have to use wglGetProcAddress (...) or an extension loading library to use glBindFramebuffer (...). You have been spoiled by Mac OS X, which is more of the exception than the rule when it comes to API completeness out-of-the-box.
My system's default version for OpenGL and GLSL using freeglut is 4.1, also using glew there is no problem with its initialization, shader compilation and linking, and execution.
This default version happens when I don't specify glutInitContextVersion, glutInitContextFlags or glutInitContextProfile, then my shaders work correct.
Regardless I have support to this version, I would like to provide a 3.3 alternative. When I use the glut context specifying the 3.3 version, the application starts with no errors, glew doesn't complain. My shaders are suppose to use the GLSL 3.3 version, then I set the line
#version 330
But when my shaders are compiled, OpenGL complains with an invalid enumerant message. I tried removing this line or setting it to another version but I still get the same error. After all initialization has been properly done, i ask for the OpenGL version and I get the right 3.3, but for the GLSL version am still getting the default 4.1.
glGetString(GL_SHADING_LANGUAGE_VERSION);
Please correct me if am right, I guess this version is overwritten by the version line in the shaders code. I wonder if there is a chance to initialize the context specifying the GLSL version too?
I finally solved it. If I set the core profile along with the compatibility mode
glutInitContextProfile(GLUT_CORE_PROFILE | GLUT_COMPATIBILITY_PROFILE);
OpenGL commands from 2.1 version won't be recognized. This goes against the information provided in the tutorials. Anyways by only setting the GLUT_COMPATIBILITY_PROFILE it works, using 3.3 or greater version.