glfwOpenWindowHint() problem

Using GLFW
MG_code
2010-09-27
2012-11-08
  • MG_code
    MG_code
    2010-09-27

    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

     
  • Camilla Löwy
    Camilla Löwy
    2010-09-27

    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).

     
  • MG_code
    MG_code
    2010-09-28

    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!

     
  • MG_code
    MG_code
    2010-09-28

    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

     
  • Camilla Löwy
    Camilla Löwy
    2010-09-28

    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.

     
  • MG_code
    MG_code
    2010-09-28

    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…

     
  • Camilla Löwy
    Camilla Löwy
    2010-09-28

    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.

     
  • MG_code
    MG_code
    2010-09-28

    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.

     
  • Camilla Löwy
    Camilla Löwy
    2010-09-28

    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.

     
  • MG_code
    MG_code
    2010-09-28

    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.

     
  • Camilla Löwy
    Camilla Löwy
    2010-09-28

    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.

     
  • MG_code
    MG_code
    2010-09-29

    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…

     
  • MG_code
    MG_code
    2010-09-29

    Whoops, forgot to add the output & errors:
    http://pastebin.com/M1agGtDV

     
  • MG_code
    MG_code
    2010-09-29

    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

     
  • MG_code
    MG_code
    2010-09-29

    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.