Sign in to follow this  
ChugginWindex

OpenGL 3.x context creation in GLFW

Recommended Posts

ChugginWindex    187
In the GLFW spec, it mentions window hints for both GLFW_OPENGL_FORWARD_COMPAT, and GLFW_OPENGL_CORE/COMPAT_PROFILE. What exactly is the difference? The core profile should only work in OpenGL 3.2 or greater, and I THINK shouldn't contain legacy code either (hence the existence of the *COMPAT_PROFILE). If that's the case, then why is GLFW_OPENGL_FORWARD_COMPAT even necessary, considering it's only relevant on contexts > 3.0? Is this just to provide some support for the fuzzy area between OpenGL 3.0 and OpenGL 3.2? Or am I missing something entirely?

Edit: The only thing I can immediately detect different is that setting GLFW_OPENGL_FORWARD_COMPAT to true causes an immediate crash on window creation due to stack corruption =/

Share this post


Link to post
Share on other sites
Trienco    2555
[quote name='ChugginWindex' timestamp='1306899279' post='4818143']
Edit: The only thing I can immediately detect different is that setting GLFW_OPENGL_FORWARD_COMPAT to true causes an immediate crash on window creation due to stack corruption =/
[/quote]

Are you sure it's a stack corruption? Playing with these hints as soon as I request a 3.0 context or use the core profile (or forward compat) it seems to crash on the first non-core function because it doesn't exist anymore (ie. the function pointer is 0).

Share this post


Link to post
Share on other sites
ChugginWindex    187
[quote name='Trienco' timestamp='1306902665' post='4818152']
Are you sure it's a stack corruption? Playing with these hints as soon as I request a 3.0 context or use the core profile (or forward compat) it seems to crash on the first non-core function because it doesn't exist anymore (ie. the function pointer is 0).
[/quote]

Yeah, I apply the hints and then try to call glfwOpenWindow(), which uses the hints that I've put in so far, but the function call fails.

This is what Visual Studio 2010 throws up when I call glfwOpenWindow():
[code]
Run-Time Check Failure #2 - Stack around the variable 'attribs' was corrupted.
[/code]

Share this post


Link to post
Share on other sites
zacaj    667
I had this problem before, if I remember correctly, after debugginh into GLFW, it turned out to be a bug in their code, with them only allocating attribs[7], and needing like attribs[15]. After changing that and recompiling GLFW, it worked, but I cant remember if that was the real answer or just some hack I did at one point before finding something wrong in my code. Can you post all your GLFW init calls, and the order theyre called in? I know I also had a problem with accidently calling glfwHint multiple times.

According to Appendix E of the opengl 3.3 core spec, Forward compatable means that you cant use functions that are planned to be removed in later versions of openGL, to make applications compatable with future versions of the spec, and not just the current version. I hope I explained that well

Share this post


Link to post
Share on other sites
ChugginWindex    187
[quote name='zacaj' timestamp='1306957908' post='4818410']
I had this problem before, if I remember correctly, after debugginh into GLFW, it turned out to be a bug in their code, with them only allocating attribs[7], and needing like attribs[15]. After changing that and recompiling GLFW, it worked, but I cant remember if that was the real answer or just some hack I did at one point before finding something wrong in my code. Can you post all your GLFW init calls, and the order theyre called in? I know I also had a problem with accidently calling glfwHint multiple times.

According to Appendix E of the opengl 3.3 core spec, Forward compatable means that you cant use functions that are planned to be removed in later versions of openGL, to make applications compatable with future versions of the spec, and not just the current version. I hope I explained that well
[/quote]

Okay yeah that makes sense. I'm just kinda confused still on what the difference is there between that, and using the OpenGL 3.3 core profile, which should have already removed all the deprecated stuff...

Unless what they're saying is that even in the GL 3.3 core profile, there's stuff that they plan to remove from, say, 4.1? If so they're really churning through features fast!

Edit: Okay I just read up on the appendix E you mentioned in the 3.3 core spec. and I think I understand the difference between the core profile and the forward compatible mode. Looks like forward compatible mode achieved what I THOUGHT the core profile did by itself, but the core profile instead just manipulates some stuff with the ARB extensions to support features on 3.1 contexts instead of just 3.3. I guess the only question left is why GLFW hates it so much when I put it in forward compat mode. I'll post my code in a minute so you can take a look.

Code: This is essentially just a combination of two GLFW 2.7 examples that they distribute with the full source code, but there might be something funky none the less.
[code]#define MAX_NUM_MODES 400

int main() {
GLFWvidmode dtmode, modes[ MAX_NUM_MODES ];
int modecount, i;

// Initialize GLFW
if( !glfwInit() )
{
exit(EXIT_FAILURE);
}

// Show desktop video mode
glfwGetDesktopMode( &dtmode );
printf( "Desktop mode: %d x %d x %d\n\n",
dtmode.Width, dtmode.Height, dtmode.RedBits +
dtmode.GreenBits + dtmode.BlueBits );

// List available video modes
modecount = glfwGetVideoModes( modes, MAX_NUM_MODES );
printf( "Available modes:\n" );
for( i = 0; i < modecount; i ++ )
{
printf( "%3d: %d x %d x %d\n", i,
modes[i].Width, modes[i].Height, modes[i].RedBits +
modes[i].GreenBits + modes[i].BlueBits );
}

glfwOpenWindowHint(GLFW_WINDOW_NO_RESIZE, GL_TRUE);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MAJOR, 3);
glfwOpenWindowHint(GLFW_OPENGL_VERSION_MINOR, 3);
glfwOpenWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwOpenWindowHint(GLFW_OPENGL_FORWARD_COMPAT, GL_TRUE); //This is what fails for me, setting it to GL_FALSE works just fine

if (GL_TRUE != glfwOpenWindow(800, 600, 0, 0, 0, 0, 0, 0, GLFW_WINDOW))
{
fprintf(stderr, "ERROR: Unable to create the OpenGL context and associated window\n");
exit(EXIT_FAILURE);
}

printf("OpenGL Context: %d.%d\n", glfwGetWindowParam(GLFW_OPENGL_VERSION_MAJOR), glfwGetWindowParam(GLFW_OPENGL_VERSION_MINOR));

while(true) {
if(!glfwGetWindowParam(GLFW_OPENED)) {
break;
}

glfwSwapBuffers();
}

// Terminate GLFW
glfwTerminate();

return 0;
}[/code]


[b]Final Edit: [/b]Well, that was dumb... I didn't realize until I said it here that I never considered the possibility that the two GLFW examples I was mixing together weren't BOTH GL 3.3 compliant (at least forward-compatibility-wise). That was the problem. I was mixing an example on how to open a GL 3.3 core profile context with an example on how to get video mode information back from the graphics card, which apparently can't be done in OpenGL 3.3 Core??? I guess this solves it, but it's also got me wondering how they expect anyone to query video format information in the new opengl...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By ZeldaFan555
      Hello, My name is Matt. I am a programmer. I mostly use Java, but can use C++ and various other languages. I'm looking for someone to partner up with for random projects, preferably using OpenGL, though I'd be open to just about anything. If you're interested you can contact me on Skype or on here, thank you!
      Skype: Mangodoor408
    • By tyhender
      Hello, my name is Mark. I'm hobby programmer. 
      So recently,I thought that it's good idea to find people to create a full 3D engine. I'm looking for people experienced in scripting 3D shaders and implementing physics into engine(game)(we are going to use the React physics engine). 
      And,ye,no money =D I'm just looking for hobbyists that will be proud of their work. If engine(or game) will have financial succes,well,then maybe =D
      Sorry for late replies.
      I mostly give more information when people PM me,but this post is REALLY short,even for me =D
      So here's few more points:
      Engine will use openGL and SDL for graphics. It will use React3D physics library for physics simulation. Engine(most probably,atleast for the first part) won't have graphical fron-end,it will be a framework . I think final engine should be enough to set up an FPS in a couple of minutes. A bit about my self:
      I've been programming for 7 years total. I learned very slowly it as "secondary interesting thing" for like 3 years, but then began to script more seriously.  My primary language is C++,which we are going to use for the engine. Yes,I did 3D graphics with physics simulation before. No, my portfolio isn't very impressive. I'm working on that No,I wasn't employed officially. If anybody need to know more PM me. 
       
    • By Zaphyk
      I am developing my engine using the OpenGL 3.3 compatibility profile. It runs as expected on my NVIDIA card and on my Intel Card however when I tried it on an AMD setup it ran 3 times worse than on the other setups. Could this be a AMD driver thing or is this probably a problem with my OGL code? Could a different code standard create such bad performance?
    • By Kjell Andersson
      I'm trying to get some legacy OpenGL code to run with a shader pipeline,
      The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
      I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.
      I've got a version 330 vertex shader to somewhat work:
      #version 330 uniform mat4 osg_ModelViewProjectionMatrix; uniform mat4 osg_ModelViewMatrix; layout(location = 0) in vec4 Vertex; layout(location = 2) in vec4 Normal; // Velocity layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location? out VertexData { vec4 color; vec3 velocity; float size; } VertexOut; void main(void) { vec4 p0 = Vertex; vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f); vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz; VertexOut.velocity = velocity; VertexOut.size = TexCoord.y; gl_Position = osg_ModelViewMatrix * Vertex; } What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.
      What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.
      Question:
      What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?
       
      Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.
    • By markshaw001
      Hi i am new to this forum  i wanted to ask for help from all of you i want to generate real time terrain using a 32 bit heightmap i am good at c++ and have started learning Opengl as i am very interested in making landscapes in opengl i have looked around the internet for help about this topic but i am not getting the hang of the concepts and what they are doing can some here suggests me some good resources for making terrain engine please for example like tutorials,books etc so that i can understand the whole concept of terrain generation.
       
  • Popular Now