Setting Up Development My Eviroment

Good Day everyone I had some questions regarding setting up a suitable environment to develop in.

I am trying to get a development environment set up using mingw specifically mingw-w64 on windows 7 64 bit. I have played around a little with opengl with header provided by the standard 32 bit mingw by including #include <gl/gl.h> but the API are dated. I have an ATI graphics card and after doing some searching on google I know there is a vendor specific file called glATI.h, but I have no idea how to set this up or even get it. When I look on the AMD developers page I see lots of information regarding OpenCL, but can not find much information regarding openGL. It just kinda appears to be buried. I have looked at glew and glut but not sure if I really want to use those. I am wanting to use as few libraries and abstraction layers as possible. So any advice and tips would be helpful.

You need to set up a window with an OpenGL context and you will need to load the OpenGL function pointers. For that I would highly recommend GLEW for the function loading and glfw for the window/context (Free GLUT would also work). You don’t need an ATI specific header.

Use glew as you seem confused with a simple gl.h it makes a lot of stuff much easier if “getting function pointers at runtimes” sound complex to you.
Glut : not that useful. Do you want to do a cross-platform program ?

I am not cocerned with cross platform development currently as this is not a production task. I am mainly learning openGL for possible use in future projects.

I have no problem binding OpenGL to a window. I am quite familiar with the WIN32 API so that’s not issues for me. So when you mention function pointers I assume your referring to dynamically linking to a dll file at run time and if that is what your referring to by “getting function pointers at run-time” like using GetProcAddress to link to the dll at run time then no its not too complex. I do see there is a function called wglGetProcAddress which would return the pointer to a function. I might asking more than I need to just to get started with openGL, but I am trying to piece together how everything is linked together. Partly, I am curious on how OpenGL manages to be implemented on so many system configurations, and retain compatibility. I guess that is the reason I want to use as few libraries and abstraction/wrapper layers as possible. Just to get a feel on how it works, since cross platform compatibility is one of the reasons I interested in OpengGL. So if one were to use wglGetProcAddress it would appear to me they would not need Glew/Glut or some other library.

Thinking about wglGetProcAddress has got me curious about a certain situation though. Maybe this is a non issue, but a lot more systems are coming out have both dedicated and integrated graphics how would your control which implementation of the openGL standard are you pointing to with just wglGetProcAddress. Like a system with Intel integrated graphics and then a discrete ATI/NVIDIA card? An even more confusing situation is system running a NVIDIA and ATI card with dual displays and each display having a dedicated card? Obivously each display is running off a different driver so if the user moved the application to the other monitor what would happen? Does that mean I would have to actively check for changes to the function pointer and ensure it is pointing the proper function?

Overall, it would be recommended that I use something like GLEW instead of trying to manage this myself correct?

You can load all needed functions with wglGetProcAddress if you like…
As for different graphics cards, you would want to check which OpenGL version is supported and loading only the supported function pointers (same with extensions), see http://www.opengl.org/sdk/docs/man/xhtml/glGetString.xml.

It can get a bit tricky.[ul][li]In windows, OpenGL function pointers are pixel format specific. []By choosing a specific pixel format you can choose which accelerator you use.[]For each window you can only call SetPixelFormat once.[]To access certain pixel formats, you need to use some extensions; but you need to have a dummy context before you can retrieve function pointers.[]Don’t try to call DescribePixelFormat on WGL pixel format, it only works with GDI pixel formats.[/ul]Here are some useful extensions:[ul][]http://www.opengl.org/registry/specs/ARB/wgl_pixel_format.txt []http://www.opengl.org/registry/specs/ARB/wgl_create_context.txt[]http://www.opengl.org/registry/specs/ARB/wgl_create_context_robustness.txt[]http://www.opengl.org/registry/specs/ARB/multisample.txt[]http://www.opengl.org/registry/specs/ARB/color_buffer_float.txt[]http://www.opengl.org/registry/specs/ARB/framebuffer_sRGB.txt[/ul]Edit: Glew has some issues with core / forward compatible contexts, so I do not use it. I am currently using glfw, with a lots of calls to glfwGetProcAddress() during initialization. I have not tried https://github.com/skaslev/gl3w but it is supposed to work better than glew with core / forward compatible contexts.[/li]

I am not sure what advantage there is of getting the addresses yourself, when GLEW can do it. It simply saves a lot of effort, with minimal overhead.

If you use glfw, there is almost no Windows API needed. And I would also recommend glfw rather than glut. If you still decide to go for glut, don’t do it; use Freeglut instead.

The only sane reason to do everything on the bare win32 API is to see how it works, which is a fine reason. If learning OpenGL itself is the goal, use additional libs.

The only sane reason to do everything on the bare win32 API is to see how it works, which is a fine reason.

Maybe he’s making, gasp, a Win32 application! You know, not making something portable? There are people who do that.

Granted, why he’s doing that and using OpenGL escapes me…

Even if I wanted to build a purly win32 app with no portability in mind I wouldn’t try to invent the wheel myself. More so if I would just start learning GL itself. But as I said, if the main goal is to learn how everything fits together it’s fine to load all the pointers on you own.

[quote=“menzel”]

Even if I wanted to build a purly win32 app with no portability in mind I wouldn’t try to invent the wheel myself. More so if I would just start learning GL itself. But as I said, if the main goal is to learn how everything fits together it’s fine to load all the pointers on you own. [/QUOTE]

The funny thing is that this is the usual result with 90% of all questions in this forum. There is a question, but never enough requirements to make it possible to give the best answer.

And because of that, you will usually see several different answers. If we are lucky, there will be a heated debate, based on different interpretations of the original question.

Well lets not have any flaming debates here. Your guys tid bits of information was helpful as it gave me ideas where and what to look for. That in itself is extremely helpful. I generally look at various sources to figure stuff out so knowing where to look was a great help. I ended up using GLFW because it seemed like a pretty clean solution, although I have experimented with fully native API. I just thought I would post some of the sources I found for future reference for others.

OpenGL Wiki Loading Extensions
Lecture Slide
A tutorial
A C# tutorial - Still had usefull information even though I program in C++

I also found resource regarding GLFW helpful since it is not an extension library and leaves loading extensions to the programmer. Also the numerous bits of info on the OpenGL registry and site. Plus numerous other sources I have stumbled upon.

I think knowing how to load the openGL extensions your self is good thing since it lets you get access to the latest functions without having to wait for a 3rd Party to extend their library. Just my thoughts.