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.
Related
I've installed Qt 5.12 , When i want to compile my project show this
errors:
Errors :
QOpenGLShaderProgram::uniformLocation(qt_Matrix): shader program is not linked
ensureInitialized(141): D3D compiler module not found.
QOpenGLShader::link: D3D compiler module not found.
shader compilation failed:
"D3D compiler module not found.\n"
Welcome to SO!
First of all, let's clarify what the error means.
Qt uses ANGLE on Windows, which is a layer that allows to run OpenGL software on systems where OpenGL is not available, by traslanting the OpenGL calls into DirectX calls. Qt decides whether to go with pure OpenGL or ANGLE depending on the configuration of the machine (video card model, video drivers version, etc).
More details on that are available at https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL.
Even if you are not writing any OpenGL code yourself, the qml runtime surely has a lot of OpenGL calls that again, may go through ANGLE.
That is why the confusing error message (looking for the D3D shader compiler while dealing with OpenGL code!).
Now, the Qt project bugtracker reports the same issue you have https://bugreports.qt.io/browse/QTBUG-71510, although at the time of writing no solution has been provided. I would suggest to have a look at the bugtracker now and then to monitor the progress on this issue.
A couple of workarounds you may try:
Copy the d3dcompiler_xx.dll in the same directory where your exe is;
Force Qt to use OpenGL instead of DirectX, by setting the environment variable QT_OPENGL to desktop (more details on that are at http://doc.qt.io/qt-5/windows-requirements.html)
According to bugreports.qt this issue is now fixed from version QT 5.12.1.
https://bugreports.qt.io/browse/QTBUG-71510
I have the same issue on my older Del laptop. Placing d3dcompiler_43.dll in the exe folder does solve the issue. I found using one of the following commands also works, which I assume avoids ANGLE all together.
//To use pure OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
//Or use software emulated OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
I just include the first pure OpenGL setting in the "int main(int argc, char *argv[])" bracket in main.cpp
I have been coding OpenGL for a while now using Java and LWJGL. However recently I decided that I would switch from Java to C++.
I managed to set up OpenGL with Visual Studio 2013, and had some fun with that. However I am used to using modern OpenGL (shaders, vbo's, vao's etc...), and I believe what I am looking for is OpenGL ES.
I have been using the GLFW library to create a window with OpenGL context, so how do I do this with OpenGL ES.
I tried adding the #define GLFW_INCLUDE_ES31 line to above the glfw3.h include, however then it cannot find the GLES3/gl31.h header file. I don't know how to obtain this file on my computer, because the GL/gl.h file was just on my computer by default.
Am I supposed to download it?
Apparently OpenGL ES is aimed at smartphones or less powerful devices, so I was wrong in thinking I wanted to use OpenGL ES. In that case, how can I use these newer functions within Visual Studio, and C++. At the moment I only seem to have access to OpenGL 1.1 functions.
You are lacking a loader (GLEW for example)
"just" add it to your project and you will be able to use the GL_ functions again
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.
I'm trying to setup VC++ to compile code with OpenGL 4.1 functionality. I downloaded the 3 header files from from opengl.org; put them in the correct paths and include them - but keep getting errors like this:
error C3861: 'wglSwapIntervalEXT': identifier not found
I have the latest video drivers. OpenGL says the problem is MS includes only version 1.1 with their compiler when though the vendor/driver supports 4.1.
One of the big pains of using OpenGL on Windows is that the Windows SDK only ships with OpenGL 1.1. There's probably a really good technical (and non-political) reason for this, but the fact remains, if you want to do anything with OpenGL on Windows, you're on your own.
What you need then, is something to bring the Windows SDK up to current standards (OpenGL 4.1 as I write this.) When I was originally trying to solve this problem (around the time of OpenGL 3.0), I came across GLee http://elf-stone.com/glee.php which is a cool library which makes the full OpenGL spec available easily. I didn't like their license, so I decided to write my own extension loader.
I don't think anyone should ever have to do this again, so I've made mine public domain, do with it as you will. I'd like to hear if you use it in something, but that's not a requirement.
http://www.onemanmmo.com/index.php?cmd=newsitem&comment=news.1.28.0