Look up, WGL_DRAW_TO_PBUFFER_ARB see that it is part of the WGL_ARB_pbuffer extension.
Look up what video cards that have that extension:
http://www.delphi3d.net/hardware/extsupport.php?extension=WGL_ARB_pbuffer
End of the day is that you will have to test on cards you want to support.
(If you are starting an application, you would usually keep track of what extensions you use)
Ok. Well, the tricky bit with extensions is that at some point in time they may be included in the core API, and then it may not be supported as an extension any more.
For instance, fragment programs are now a part of OpenGL 2.0 and thus the cards don’t have to support the extension as long as they comply to OpenGL 2.0. However it is common to keep it as a supported extension as well.
To conclude… the hard part is not to test the support when running the app. The hard part is to write a good and simple hardware requirement specification, so that the user knows whether it will work on his/her hardware even before trying.
Originally posted by lubbe75:
Ok. Well, the tricky bit with extensions is that at some point in time they may be included in the core API, and then it may not be supported as an extension any more.
I am not aware of that ever happening.
To conclude… the hard part is not to test the support when running the app. The hard part is to write a good and simple hardware requirement specification, so that the user knows whether it will work on his/her hardware even before trying.
Yes, but YOU should have tested it, not your users.
As I said above, you should know what functionality is needed by your app, so you should know what cards will run it. (Infact, you should be testing for extension and version support in your app - Need FBO? you should be checking for it’s extension strings’ existance before using it. So you can simply look at all the extension/version checks to know what cards you support. Not doing thses checks is just asking for trouble.)
If you are part of a larger team you probably need more coordination - but even so for less than 1000$ (nothing for a software dev house) you can buy a low end version of each card generation to test on. (Geforce 5200, 6200, 6600 + Radeon 9550 etc) But a software house probably has these cards lying around anyway through computer upgrades.
Yes, I suppose testing is the only way to really know for sure. The problem is that testing takes time… especially when there are so many cards and series out there to test.
Talking about testing graphics hardware, it would be really nice to have one ATI card and one Nvidia card installed on the same machine, so that you could easily switch between them during development, for unit testing. I have never heard of such a rig. But that’s another story. We are already quite a bit off the topic here.
So… in the list above I could, for instance, try to google on wglGetExtensionsStringARB and hopefully find the name of the extension that needs to be supported
No, you don’t need google to determine what extensions is required for each function/token. From my previous post:
Just look at glew.h - each extension is in separate section - you can see it’s name in comment at beginning of every section and if it’s core functionality then you’ll see what version of OpenGL to require.
Originally posted by lubbe75:
Ok. Thanks. So there is no simple tool or anything that I can use for this purpose? Something like a opengl-debugger or something?
BuGLe has a module which will take a guess at what extensions were used, based on the functions called and tokens passed. It’s not perfect because some token values have multiple names (both promotions like GL_ARRAY_BUFFER_ARB == GL_ARRAY_BUFFER and overlaps like GL_POINTS == GL_NO_ERROR), and some extensions can be used without any tokens or functions (e.g. GL_ARB_texture_non_power_of_two).
I suspect from your sample code though that you’re using Windows, in which case BuGLe won’t help you 