Why some GL Image functions requires using GL Load to initialize OpenGL context ? Is it possible to fully utilize GL Image using GLEW to initialize OpenGL context ?
If you are talking about the Unofficial SDK's GL Image system, the answer is no. The SDK is intended to be a package deal; if you're using one part of it, you ought to be using the rest. After all, if you can build and include GL Image, you could also use GL Load, since they're bundled together.
And GL Load does exactly what GLEW does; it's better in many ways, as it doesn't require that "experimental" thing to make it work on core contexts. Through the C interface, you could just swap out all of the #include <GL/glew.h> parts with #include <glload/gl_[Insert Version Here].h>. You wouldn't need to modify any code other than that (as well as the initialization code of course).
That being said, you ought to be able to use GL Load and GLEW simultaneously, as long as:
You initialize both of them. This means calling glewInit and LoadFunctions after creating the OpenGL context. Their variables shouldn't interact or anything.
You never try to include both of their non-system headers in the same file. GL Image's TextureGenerator.h is actually designed specifically to not require the inclusion of OpenGL headers (that is, it doesn't directly use GL types like GLint or GLenum).
It's obviously wasteful, as they do the exact same job. But it ought to work.
Related
Whenever I call a function to swap buffers I get tons of errors from glDebugMessageCallback saying:
glVertex2f has been removed from OpenGL Core context (GL_INVALID_OPERATION)
I've tried using both with GLFW and freeglut, and neither work appropriately.
I haven't used glVertex2f, of course. I even went as far as to delete all my rendering code to see if I can find what's causing it, but the error is still there, right after glutSwapBuffers/glfwSwapBuffers.
Using single-buffering causes no errors either.
I've initialized the context to 4.3, core profile, and flagged forward-compatibility.
As explained in comments, the problem here is actually third-party software and not any code you yourself wrote.
When software such as the Steam overlay or FRAPS need to draw something overtop OpenGL they usually go about this by hooking/injecting some code into your application's SwapBuffers implementation at run-time.
You are dealing with a piece of software (RivaTuner) that still uses immediate mode to draw its overlay and that is the source of the unexplained deprecated API calls on every buffer swap.
Do you have code you can share? Either the driver is buggy or something tries to call glVertex in your process. You could try to use glloadgen to build a loader library that covers OpenGL-4.3 symbols only (and only that symbols), so that when linking your program uses of symbols outside the 4.3 specs causes linkage errors.
I am using Open GL 3.0
I am trying to update this example to modern OpenGL :
http://qt-project.org/doc/qt-4.8/opengl-hellogl-es.html
I am also looking at this example:
http://qt-project.org/doc/qt-5/qtopengl-cube-example.html
I am looking at the OpenGL ES examples, because they compiled and rendered easily on my machine, and the OpenGL ES 2 example uses some programmable pipelining.
I want to use the pipeline functions referenced in this tutorial:
http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/
For instance glGenBuffers()
However, this does not seem to come up in open Qt. If I try to compile a program that uses glGenBuffers, or glBindBuffer.
Why can I use some Open GL functions but not others?
Looking at the second example (OpenGL ES2) There is a type "QGLShaderProgram" which seems to wrap some of the shading functions, but I am at loss as to how to follow even a simple open GL tutorial with full access to the rendering functions.
For instance, the openGL tutorial references at least half a dozen functions I can't seem to use. I would be fine with this, but I can't seem to find where the Qt folks have explained what functions are wrapped, or covered up, or are absent.
Could I be missing an include or something?
I am including #QGLWidget and #QtOpenGL
See below for my answer to your question. However, it seems likely you are looking for a simpler OpenGL example with Qt like the triangle one you linked to. I also made an introductory post here where you can learn the basics of how Qt and OpenGL work together before you start an example.
First of all use Qt 5.5 now. It is configured with the -opengl dynamic option by default which might solve your problem. If you don't have -opengl desktop configure option set in your pre 5.5 build of Qt then you won't have access to modern OpenGL functions other than the subset of OpenGL ES 2 that is supported by all the platforms Qt supports.
Second, don't use the QGL* functions or classes as they are old/deprecated now. They were replaced by the QOpenGL* functions and classes.
As for includes, you will need a QOpenGLFunctions or QOpenGLFunctions_3_0 to know for sure which set of functions you are getting. You will also need any other classes like QOpenGLBuffer QOpenGLVertexArrayObject... or just include QtGui as that is where all the OpenGL functions and classes are now.
As a budding game developer here, I am currently practicing with C++ and OpenGL graphics, and the desire is to assemble a skeleton project that I can both use for small game projects, as well as share with some friends with like interest.
The target is OpenGL 3.3+ (using no deprecated mechanisms such as 'glBegin' etc.), using the libraries SDL 2.0, GLEW 1.10.0 (with WGLEW) and GLM 0.9.4.5. I'm developing with Visual Studio 2012, and primarilly for Windows, but multi-platform compatibility is also desireable if possible to achieve.
The problem at hand is that I am now trying to implement Anti- Aliasing. Most sources appear to tell me that in order to achieve this, I first need to create a dummy context, in order to get access to certain OpenGL functionality, activating multisampling, and lastly spawn a proper rendering context. As described on [OpenGLs pages](http://www.opengl.org/wiki/Creating_an_OpenGL_Context_%28WGL%29"Creating an OpenGL Context").
What I ponder then, is this;
Most guides, examples and other, tend to either mix SDL-functionality and OpenGL calls, or build functions focusing entirely on OpenGL calls. While I would be able to reproduce this with some digital elbow grease; half the reason I desire to use SDL is not to have to manage window handles, pixelformats and such too much myself, but let SDL take care of this.
As such I ask you now;
Can I somehow create a dummy context, initiate things such as Multisampling and Anisotropy, and transfer into a proper context solely through support libraries such as SDL 2.0, or will I have to get my hands into the OpenGL API (preferably through GLEW then) and build a few launcher functions such as others have? If I need to myself, would not much of the purpose of SDL be lost?
When using SDL 1.2, what do I need to include to be able to use OpenGL Vertex Buffer Objects (VBOs)?
Currently, I only include SDL.h, SDL_opengl.h, SDL_image.h
And get the errors:
glGenBuffersARB, glBindBufferARB, glBufferDataARB not declared in this scope
If you want to use SDL_opengl.h define GL_GLEXT_PROTOTYPES before including it.
#define GL_GLEXT_PROTOTYPES
#include "SDL.h"
#include "SDL_opengl.h"
I may or might not work. If you want to do it the "proper" way, use something like glew.
You should include <GL/gl.h> and <GL/glext.h>. Sometimes OpenGl extension functions are not directly available and must be loaded using SDL_GL_GetProcAddress (this returns the function pointer or 0 if extension is not available). You may be interested to have a look to libglew which loads the extension functions.
Here is how you may do it (if not using glew):
extern PFNGLGENBUFFERSARBPROC glGenBuffers; // Function pointer declaration, in a header file.
// Function pointer initialization
glGenBuffers = 0;
// Get the function (you should have checked that extension is available)
glGenBuffers = (PFNGLGENBUFFERSARBPROC)SDL_GL_GetProcAddress("glGenBuffersARB");
It is possible to get the underdevelopment 1.3 version of SDL to open a OpenGL 3.2 context with a bit of work.
It's also worth checking out SFML, it's similar to SDL but is hardware accelerated for the 2D stuff, object orientated C++ and is much easier to use. OpenGL is particularly simple to use with it. Once again it's the development 2.0 version that supports OpenGL 3.2 contexts (although it's close to being released.)
You will probably need to use the non-ARB versions with the above.
I find the SDL_opengl.h file to be fairly useless. Personally, I recommend using GLEW or GLee. GLee is easier to add to your project but stops at OpenGL 3.0 (usually fine in SDL apps since SDL only enables an OpenGL 2.1 context). GLEW requires just a bit more work but enables stuff up through OpenGL 4.
I ran into this same problem regarding VBOs in SDL.
i have a program that does some GPU computing with Optional OpenGL rendering.
The use dynamic is as follow:
init function (init GLEW being the most relevant).
load mesh from file to GPU (use glGenBuffers are related functions to make VBO).
process this mesh in parallel (GPU Computing API).
save mesh into file.
my problem is that when mesh is loading i use opengl calls and wihout context created i just
get segmentation fault.
Edit: Evolution of the problem:
I was missing GL/glx.h I thought that GL/glxew.h included it, thanks to the answers that got fixed.
I was missing glXMakeCurrent; and therefore it was having zero contexts.
After this fixes, it works :).
also thanks for the tools suggestions, i would gladly use them it is just that i needed the low level code for this particular case.
i tried making a context with this code ( i am using glew, so i change the header to GL/glxew.h but the rest of this code remains the same)
Don'd do it. glxew is used for loading glx functions. You probably don't need it.
If you want to use GLEW, replace GL/gl.h with GL/glew.h leave GL/glx.h as it is.
X11 and GLX are quite complex, consider using sdl of glfw instead.
Just wildly guessing here, but could it be that GLEW redefined glXChooseFBConfig with something custom? Something in the call of glXChooseFBConfig dereferences an invalid pointer. So either glXChooseFBConfig itself is invalid, or fbcount to so small, or visual_attribs not properly terminated.
GLEW has nothing to do with context creation. It is an OpenGL loading library; it loads OpenGL functions. It needs you to have an OpenGL context in order for it to function.
Since you're not really using this context for drawing stuff, I would suggest using an off-the-shelf tool for context creation. GLFW or FreeGLUT would be the most light-weight alternatives. Just use them to create a context, do what you need to do, then destroy the windows they create.