The above function causes GLFW to fail to open a window a lot of the time for
me.
I'm using:
MinGW
Windows Vista
nVidia Quadro NVS 140M with latest drivers (8.17.12.5896)
GLFW latest precompiled release (statically linked)
I can get OpenGL 3.3 with my card, and by default GLFW will use this version.
But if I explicitly request this version via the above function, it fails
intermittently (I haven't quite managed to reproduce this reliably yet…)
What I CAN reproduce is GLFW's failure to open a window if I request a
forward-compatibility context or a core profile.
The following code I hashed up illustrates my problem. Below is the code and
it's output on my machine. Any help would be appreciated.
Your test program is broken. glfwOpenWindow resets all window hints to their
default values. You should also not close windows using glfwTerminate and
glfwInit. glfwCloseWindow is sufficient. Here's an updated version:
Wow, I messed that up then. Your revised program gives me the following
output, which is much closer to what I'd expect (stdout followed by stderr): http://pastebin.com/tSXrRE8d
To cut a long story short, GLFW seems to have been choking on the bit depths I
requested via glfwOpenWindow. I noticed your code passes in 0 for every one,
while I was passing 8. The former works but the latter does not.
Thanks a lot for your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, I spoke too soon. The window now opens fine, but
glfwGetWindowParam() tells me I don't actually have a forward compatibility
context OR the core profile: http://pastebin.com/p5BXjW7b
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm, 8 is an odd number for depth buffer bit count (which is usually 24 or
32), although it should still work using 8. If it doesn't, that's a bug in
GLFW.
The latter problem definitely is a bug in GLFW. It seems we're not setting
those two window params. I'm adding it to 2.7.1. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A final note: drawing a rotating pyramid (using http://pastebin.com/3DQ2EmCV) produces a
blank screen, if I explicitly requested a GL 3.3 or 3.2 context via
glfwOpenWindowHint().
If I request GL 3.0 or 3.1 , GLFW reports using those versions and the pyramid
appears.
If I request any GL version lower than 3.0 , GLFW reports using GL 3.3 but the
pyramid STILL appears.
If I don't request a specific GL version at all, GLFW again reports using GL
3.3 and the pyramid appears.
You'll notice I'm deliberately using deprecated functions when drawing the
pyramid.
So to put it another way, those deprecated functions fail to work if I
explicitly request a newer OpenGL version, REGARDLESS of what version GLFW
actually gives me - it can give me a 3.3 context in which the pyramid still
draws, so long as I haven't specifically asked for that context.
All this in spite of the fact I don't have forward-compatibility or the core
profile as above.
Thanks a lot for your interest in all of this…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The default isn't to use the compatibility profile; the default is to let the
implementation decide. On my machine, requesting an OpenGL 3.2 context
(sorry, don't have 3.3 here) gives me a 3.2 core profile context. Try
explicitly requesting the compatibility profile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You're right, explicitly requesting the compatibility profile causes the
pyramid to appear with GL 3.3 / 3.2 contexts.
By default, it seems my machine uses the core profile whenever I request a
recent enough GL version.
However, if I request an older GL version (< 3.0) or don't explicitly
request one at all, I get a 3.3 context with the compatibility profile.
I should mention that in all cases, glfwGetWindowParam() returns 0 when I
ask for the currently used profile.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tha'ts the same creation behaviour I have here, with an nVidia card on Linux.
As for glfwGetWindowParam, I completely forgot to add read-back of the profile
and forward-compat params. That's why they are and always will be zero on 2.7.
Sorry about that. Fixing it in 2.7.1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, so there's a good chance my previous efforts WERE setting profile and
forward-compat modes, but glfwGetWindowParam() won't be able to confirm it
to me? That's much less of an issue, given I can guess what's going on fairly
well with the pyramid thing.
Thanks for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should say this is literally my first attempt at building other peoples'
code, but I gave it a go.
I got the tarball from here and compiled with
ming32-make.exe using compile.bat .
It produced the following output & errors:
A quick search through the tarball suggests those symbols are only defined in
version.c , which I believe is just test code.
win32\platform.h DOES include symbols which are very similar:
WGL_CONTEXT_ * _ARB as opposed to GL_CONTEXT_ *
and win32\win32_window.c uses those. I'm in the process of switching the
symbols in window.c that MinGW chokes on to see what happens…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the above symbol substitutions, GLFW compiles fine. The bundled example
and test programs work, and it seems I can now retrieve profile and forward-
compat status in my own projects via glfwGetWindowParam().
For your information, my modified lib\windows.c file is here (only a few
lines are different): http://pastebin.com/9YK0YYsQ
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ha, spoke too soon. GLFW now reports forward compatibility as enabled,
regardless of what I request via glOpenWindowHint() . The core/compat
profiles work fine though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above function causes GLFW to fail to open a window a lot of the time for
me.
I'm using:
MinGW
Windows Vista
nVidia Quadro NVS 140M with latest drivers (8.17.12.5896)
GLFW latest precompiled release (statically linked)
I can get OpenGL 3.3 with my card, and by default GLFW will use this version.
But if I explicitly request this version via the above function, it fails
intermittently (I haven't quite managed to reproduce this reliably yet…)
What I CAN reproduce is GLFW's failure to open a window if I request a
forward-compatibility context or a core profile.
The following code I hashed up illustrates my problem. Below is the code and
it's output on my machine. Any help would be appreciated.
http://pastebin.com/u7Cz6RPT
http://pastebin.com/cW2qUSEB
Your test program is broken. glfwOpenWindow resets all window hints to their
default values. You should also not close windows using glfwTerminate and
glfwInit. glfwCloseWindow is sufficient. Here's an updated version:
http://pastebin.com/HNAi4apa
You also don't need to call atexit, as glfwInit does this for you (GLFW
Reference Manual §3.1.1).
Wow, I messed that up then. Your revised program gives me the following
output, which is much closer to what I'd expect (stdout followed by stderr):
http://pastebin.com/tSXrRE8d
To cut a long story short, GLFW seems to have been choking on the bit depths I
requested via glfwOpenWindow. I noticed your code passes in 0 for every one,
while I was passing 8. The former works but the latter does not.
Thanks a lot for your help!
Actually, I spoke too soon. The window now opens fine, but
glfwGetWindowParam() tells me I don't actually have a forward compatibility
context OR the core profile: http://pastebin.com/p5BXjW7b
Hmm, 8 is an odd number for depth buffer bit count (which is usually 24 or
32), although it should still work using 8. If it doesn't, that's a bug in
GLFW.
The latter problem definitely is a bug in GLFW. It seems we're not setting
those two window params. I'm adding it to 2.7.1. Thanks.
A final note: drawing a rotating pyramid (using
http://pastebin.com/3DQ2EmCV) produces a
blank screen, if I explicitly requested a GL 3.3 or 3.2 context via
glfwOpenWindowHint().
If I request GL 3.0 or 3.1 , GLFW reports using those versions and the pyramid
appears.
If I request any GL version lower than 3.0 , GLFW reports using GL 3.3 but the
pyramid STILL appears.
If I don't request a specific GL version at all, GLFW again reports using GL
3.3 and the pyramid appears.
You'll notice I'm deliberately using deprecated functions when drawing the
pyramid.
So to put it another way, those deprecated functions fail to work if I
explicitly request a newer OpenGL version, REGARDLESS of what version GLFW
actually gives me - it can give me a 3.3 context in which the pyramid still
draws, so long as I haven't specifically asked for that context.
All this in spite of the fact I don't have forward-compatibility or the core
profile as above.
Thanks a lot for your interest in all of this…
The default isn't to use the compatibility profile; the default is to let the
implementation decide. On my machine, requesting an OpenGL 3.2 context
(sorry, don't have 3.3 here) gives me a 3.2 core profile context. Try
explicitly requesting the compatibility profile.
You're right, explicitly requesting the compatibility profile causes the
pyramid to appear with GL 3.3 / 3.2 contexts.
By default, it seems my machine uses the core profile whenever I request a
recent enough GL version.
However, if I request an older GL version (< 3.0) or don't explicitly
request one at all, I get a 3.3 context with the compatibility profile.
I should mention that in all cases, glfwGetWindowParam() returns 0 when I
ask for the currently used profile.
Tha'ts the same creation behaviour I have here, with an nVidia card on Linux.
As for glfwGetWindowParam, I completely forgot to add read-back of the profile
and forward-compat params. That's why they are and always will be zero on 2.7.
Sorry about that. Fixing it in 2.7.1.
Ah, so there's a good chance my previous efforts WERE setting profile and
forward-compat modes, but glfwGetWindowParam() won't be able to confirm it
to me? That's much less of an issue, given I can guess what's going on fairly
well with the pyramid thing.
Thanks for your help.
Yes, setting the hints works as expected in 2.7. You can verify this using the
version test, which in 2.7 doesn't rely on window parameters.
I believe I've fixed this bug in Subversion trunk now, if you want to try it
out.
I should say this is literally my first attempt at building other peoples'
code, but I gave it a go.
I got the tarball from
here and compiled with
ming32-make.exe using compile.bat .
It produced the following output & errors:
A quick search through the tarball suggests those symbols are only defined in
version.c , which I believe is just test code.
win32\platform.h DOES include symbols which are very similar:
WGL_CONTEXT_ * _ARB as opposed to GL_CONTEXT_ *
and win32\win32_window.c uses those. I'm in the process of switching the
symbols in window.c that MinGW chokes on to see what happens…
Whoops, forgot to add the output & errors:
http://pastebin.com/M1agGtDV
With the above symbol substitutions, GLFW compiles fine. The bundled example
and test programs work, and it seems I can now retrieve profile and forward-
compat status in my own projects via glfwGetWindowParam().
For your information, my modified lib\windows.c file is here (only a few
lines are different):
http://pastebin.com/9YK0YYsQ
Ha, spoke too soon. GLFW now reports forward compatibility as enabled,
regardless of what I request via glOpenWindowHint() . The core/compat
profiles work fine though.