The tutorial I’m following uses GLFW to create the window and context for OpenGL used in it’s example code.
I want to create an OpenGL context in an MS Windows window. I’ll use the application’s DialogProc() to run the application, which include rendering images in the OpenGL window.
It’s dawning on me, please correct me if I’m wrong, GLFW is pretty much a non-actor in such an environment.
All the sample code I’ve been working with set window hints with glfwWindowHint().
Some GLFW hints, like GLFW_VISIBLE, are obviously redundant if a Windows DialogProc is running the show.
With GLFW no longer being used I’m wondering what corresponds to glfwWindowHint()…
One example of a hint I think I’ll need corresponds to glfwWindowHint(GLFW_SAMPLES, 16).
GLFW and GLUT are just simplified, cross-platform toolkits. If you don’t need cross-platform support, or you need more control than those toolkits give you, then you can just use the OS’ native functions directly.
For Windows, see e.g. here. But the best reference is probably the source code for any open-source GUI toolkit with OpenGL support: e.g. GLFW, GLUT, SDL, SFML, GTK, Qt, wxWidgets. Particularly for Windows, as Microsoft tries to avoid providing anything beyond the bare minimum of support for OpenGL (they’d rather you used DirectX instead).
So you probably won’t find out how to enable multisampling from the official MSDN documentation. That requires the WGL_ARB_multisample extension, and MSDN doesn’t document extensions. You’ll need to first create a dummy window and create a context for it. Then you can query whether the WGL_ARB_multisample extension is supported and get a pointer to the wglChoosePixelFormatARB() function. That function does the same job as the (document) ChoosePixelFormat() function, but allows you to select additional features, including multisampling.
Also opengl32.dll only exports the OpenGL 1.1 API. If you need to use any function which was added in a later version (or in an extension), you need to use wglGetProcAddress() to obtain a pointer to the function (assuming that the display driver actually supports it), or use a library such as GLEW to do this for you.
I’ve been working with Windows for a long time. OpenGL is attractive because I’d like to develop for Android some day.
Windows runs the message loop in the DialogProc, I can’t get away from that. I’d like to use open tools and try to write as close to cross platform in as many functions as I can.
Other than not being well supported by Microsoft, is there any inherent disadvantage to using OpenGL over DirectX? Does OpenGL code have the same access to hardware acceleration?
I want to use best practices, and take advantage of any available and appropriate toolkits.
Yesterday morning that paragraph would have sounded like technobabble.
Last night I wrote a Windows OpenGL initialization function, including the fake window stuff for GLEW. So I understand what you’re referring to.
I’m assuming the “W” in WGL stands for Microsoft Windows.
Wglew.h is found in the GLEW download. The comments suggest it’s a product of some individuals and The Kronos Group, not Microsoft. It defines about 50 different types of integer attributes and 8 different context attributes that are passed to wglChoosePixelFormatARB().
Is there a site that describes those attributes for beginner OpenGL users?
This appears to be a list of extensions available to wglGetProcAddress(). I see a function named WGL_ARB_multisample.
Since I’m looking at sample code that uses GLFW, extensions that are equivalents to glfwWindowHint() arguments would be helpful.
Yes. The wgl* functions provide the binding between Windows and OpenGL. The glX* functions do the same thing on X11.
Wglew.h is found in the GLEW download. The comments suggest it’s a product of some individuals and The Kronos Group, not Microsoft. It defines about 50 different types of integer attributes and 8 different context attributes that are passed to wglChoosePixelFormatARB().
Is there a site that describes those attributes for beginner OpenGL users?
[QUOTE=larryl;1286456] This appears to be a list of extensions available to wglGetProcAddress(). I see a function named WGL_ARB_multisample.[/quote]
The names listed there are extensions. You can query support for extensions by examining the string returned by glGetString(GL_EXTENSIONS), which returns a space-separated list of extension names. In modern OpenGL (3+ core profile), you need to use glGetStringi() instead (but as that function isn’t in 1.1, you’d first need to create a context, query the supported version, then obtain a function pointer from wglGetProcAddress()).
Each extension may define new functions, as well as modifying the behaviour of existing functions.
Again, the best reference here will be the GLFW source code. Search for the name of the hint to find out what GLFW does with it. That will give you the name of the function; a web search should locate the extension which defines that function.
But from a brief look at the list, the following extensions relate to features which, if they’re provided by GLFW, would probably be controlled by window hints:
[QUOTE=larryl;1286456]I’ve been working with Windows for a long time. OpenGL is attractive because I’d like to develop for Android some day.
…
I want to use best practices, and take advantage of any available and appropriate toolkits.[/QUOTE]
I don’t know how big a factor potentially future Android development is in your thinking. But along that line of thought…
Android uses OpenGL ES for GPU rendering rather than OpenGL. They’re very similar in basic capability, but not the same.
Also, Android uses EGL for the windowing system interface layer, rather than WGL or GLX.
If/when you decide to do more Android-oriented development, you might choose to do EGL and OpenGL ES development on the desktop (rather than WGL / OpenGL). There are a number of options here. For instance NVidia provides EGL and OpenGL ES support in their desktop GPU drivers (on Linux at least). Imagination Technologies provides their excellent and free PowerVR SDK to give you base libraries and headers for developing EGL and OpenGL ES on top of existing desktop GL drivers and useful tools for debugging and optimizing them. Other mobile GPU venders provide desktop GL-ES libraries and development tools as well.
At some point you might want to give these a spin. It’s much easier porting your app to Android when your app is already built on EGL and OpenGL ES.
I dont know which programming language you use but if you want to develop for android devices perhaps you are using Java. If that is so you might want to have a look at the LibGDX framework which allows you to compile your code for all major desktop OS’s as well as android, webGL and iOS (if you have a license).
Not really. It uses the Linux kernel, but doesn’t aim for Linux (or POSIX) compatibility. E.g. the graphics system doesn’t use X11.
It’s possible to write complete applications in C++, but it’s discouraged. Many of the higher-level libraries are either written in Java or use the Java ABI (so you’ll need to write JNI boilerplate if you’re calling them from C++).
So you won’t be able to avoid Java entirely. You’ll at least need to learn how to interface C++ to Java even if you never write a line of actual Java code.