Installing / updating customer's OpenGL version

The application I am working on looks like it is going to need OpenGL 1.2. Perhaps 1.4. From what I understand, most Windows installations come with OpenGL 1.1 out-of-the-box.

Is there a good, standard, way for an installer program to update the customer’s drivers and OpenGL version? Some library or toolkit that can handle it? Or, at least, a good webpage to direct the customer to?

On a related note:
I updated the drivers for my ATI HD 4300/4500 series adapter.
But my OpenGL version is still reporting 1.1. Did I miss a step?

You need to use an extension handler. I recomend you to use GLEW http://glew.sourceforge.net/

you can read about why at http://opengl.org/wiki/Getting_started#OpenGL_2.0.2B_and_extensions

glew is very simple to use. For basic usage check out: http://glew.sourceforge.net/basic.html

Edit
Maybe I misunderstood your question. The opengl32.dll file in windows do only support opengl 1.1 and the only way (that I know of) to change that is to use an extension handler as mention above.
About the drivers on the custumers computer I dont know, but I believe that if they dont have to old computers I guess they support atleast opengl 1.2 (but im not sure)

If you’re using glGetString (GL_VERSION) and you still get 1.1 then one of several things has happened:[ul][li]You’re using the generic one-size-fits-all VGA driver that Windows installs when it can’t identify your hardware; in other words you haven’t actually installed a driver for your video card at all.[]Your driver genuinely only supports OpenGL 1.1; you’re screwed basically.[]Your context creation params were messed up and you’ve got a pixel format that can’t be hardware accelerated by your driver. Time to fix your code.[*]You’ve got an OEM or generic Microsoft-provided driver that doesn’t have OpenGL support so you’ll need to replace this with the chip manufacturer’s driver.[/ul]I don’t see any tool to automatically update drivers being of practical use; at the very least on Windows Vista and 7 a diver update will need to trigger a UAC prompt.[/li]
However it’s not really all bad news. I’m quite uncertain about the “most Windows installations only support OpenGL 1.1” part for starters. It’s true that Microsoft’s software implementation is locked at this version (or is it 1.2?) but any Windows PC that has a graphics chip other than Intel should support whatever GL_VERSION is appropriate for that chip via a full ICD. Machines with Intel graphics generally have OEM drivers that don’t include OpenGL support, but a quick trip to Intel’s website, a download of an Intel provided driver, and an installation using the “have disk” method fixes that.

Secondly, you may have misunderstood how OpenGL support on Windows actually works; especially if you come from a Unix background. The Windows <gl/gl.h> and opengl32.lib only have support for 1.1, true, but you can use the extension mechanism to load entrypoints for higher versions and just use them normally after that. As mentioned upthread, something like GLEW is highly recommended for a pain-free life if this is the case.

I don’t have any trouble getting the extension functions. A few years ago I swiped some code (extsetup.cpp) that fetches them. From it’s header comment block, it looks like ATI wrote it.

My concern is the customer base. The software is targeted for office computers and most of those computers do not bother updating the display drivers beyond what came installed on the machines.

As far as my personal problem with OpenGL version being only 1.1, I wonder if the problem could be that I am running it from a remote desktop session?

The software is targeted for office computers and most of those computers do not bother updating the display drivers beyond what came installed on the machines.

The most you could do is ship the NVIDIA/ATI/etc drivers with your application and install them when you install the app. However, I don’t think this is a particularly good solution. It’d be better to simply check to see if the required functionality (version number and/or extensions) is available, and if it’s not, just pop up a dialog telling them to update their drivers.

As far as my personal problem with OpenGL version being only 1.1, I wonder if the problem could be that I am running it from a remote desktop session?

I wouldn’t expect that to work well on Windows.

Hmmm, tricksy. I did business PC builds for a living some years back and can empathise. We’re firmly in Intel land here and we’re also in a territory where what software goes on a PC is strictly controlled by admins (who I doubt would take kindly to an automatic driver installer; I know I wouldn’t have in my previous life). Your users may not even have local admin rights on their PCs (and admins will take even less kindly to an app that requires them); all factors you need to consider. Maybe it’s the case that OpenGL is just the wrong choice for your user base, and you should be looking at D3D instead? Unless we’re talking about CAD users who one would expect would have capable hardware anyway.

That would certainly explain a lot. Windows RDP sessions use their own video driver which I seriously doubt has stellar graphics capabilities. http://msdn.microsoft.com/en-us/library/aa383015%28v=vs.85%29.aspx

Ya. I was starting to think the same thing. Pity.

What do you think Acrobat (Flash) uses for it’s hardware accelerated graphics?

Just an update:

Yes, Windows Remote Desktop cannot do better than OpenGL 1.1
Even if your video card can.

Apparently, it uses a generic software renderer display adapter driver.
Who’s capabilities are separate from your actual display adapter and drivers.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.