Hi,
I'm fairly new to OpenGL programming so this may be a stupid question. I understand why and how the extension thing has been added to OpenGL and how this helps OpenGL to be up to date on Windows.
But how should I use this now? I want to develop a cross platform game on Win/Mac/Linux with the latest shader techniques, vertex/geometry/pixel-shaders, and the likes.
I seem to be able to use functions like glCreateShaderObject while there also is a glCreateShaderObjectARB version (which I presume was there first). I can create a GL_VERTEX_SHADER or a GL_VERTEX_SHADER_ARB with it, but I only have a GL_GEOMETRY_SHADER_ARB, not a GL_GEOMETRY_SHADER, probably because my windows version supports up to 2.1/1.2 and not 3.0/1.3?
Should I, when trying to develop cross-platform, just always use the ARB-versions to make sure it also works on older windows systems or will the non-ARB versions also work on older systems?
Does this mean that if I want to go cross-platform, and don't want to split up my code (windows/non-windows), I will have to use the extension-versions all the time and does this hurt performance or something else?
And why does the book "More opengl game programming", a book that seems to be mainly dedicated to windows development, use the non-ARB function set?
D.
When to use ARB/...?
I'm no expert not having used any extension personally, but I'm pretty sure it's the inverse. Judging from the OpenGL Wikipedia page, the EXT/ARB functions were added after the original functions. ARB meaning Architecture Review Board.
Both non-extension and extension functions exists on every platforms, so you don't have to use them differently on one platform or another. Whether or not you can use them are limited by the video card hardware, not your OS.
Both non-extension and extension functions exists on every platforms, so you don't have to use them differently on one platform or another. Whether or not you can use them are limited by the video card hardware, not your OS.
The lifetime of an OpenGL extension is intended to go something like this. First came vendor specific extensions (like _SGIS, _NV, _ATI, etc). When a few vendors implemented the same extension it became an _EXT, to indicate that it was reasonably common and standardised. Sometimes an extension would get the seal of approval from on-high and it would become _ARB. These extensions may have previously been vendor-specific, they may have been _EXT, or they may have been completely new (or an adaptation or modification of an existing one that was reasonably different enough to be incompatible).
An _ARB extension is normally a good indicator that support is widespread and that it's going to be adopted into the core in the next version (and also drop the _ARB suffix). So GL_ARB_multitexture went into the core roundabout OpenGL 1.2.1 or 1.3, and as such it's no longer an extension if your GL_VERSION is higher than this. Again, sometimes extensions might bypass the _ARB stage and go straight into the core from either a previous stage (as I believe happened with NV_blend_square) or be completely new.
There's normally very little difference between core and _ARB, and if you check your local friendly OpenGL header file you'll see that the #defines are the same (I've yet to see a case where they aren't).
However, be aware that no 3D card is obliged to report support for *any* extensions at all (that's the point of them being "extensions"). So a card that's OpenGL 2.1 is perfectly within it's remit to not support any of the _ARB, _EXT, _NV, _ATI or whatever stuff. It's still a 100% conformant OpenGL 2.1 card even if it only supports the suffix-less versions of the entry points, although in practice this doesn't ever happen.
So which to use? I would probably lean towards checking each in the order: core (i.e. suffix-less), then _ARB, then give up. That ensures that you're getting the most correct and up to date version of the extension (and some of the older ones have really *weird* behaviour) but have a compatible fall-back in case you encounter an older driver. Another viable approach is to just check for _ARB and forget about the suffix-less versions, and I've also used this in the past. The most important thing is to be consistent, so if you're getting the entry points for any given extension, make certain that all the entry points you get for that extension are _ARB (or not, as appropriate). In theory it shouldn't matter but sometimes it does.
If all of this sounds like a horrible confusing mess (and it is), the good news is that there are libraries available - like GLEW - that will work it all out for you. So that's my final recommendation - grab a copy of GLEW and use that instead of checking extensions yourself.
An _ARB extension is normally a good indicator that support is widespread and that it's going to be adopted into the core in the next version (and also drop the _ARB suffix). So GL_ARB_multitexture went into the core roundabout OpenGL 1.2.1 or 1.3, and as such it's no longer an extension if your GL_VERSION is higher than this. Again, sometimes extensions might bypass the _ARB stage and go straight into the core from either a previous stage (as I believe happened with NV_blend_square) or be completely new.
There's normally very little difference between core and _ARB, and if you check your local friendly OpenGL header file you'll see that the #defines are the same (I've yet to see a case where they aren't).
However, be aware that no 3D card is obliged to report support for *any* extensions at all (that's the point of them being "extensions"). So a card that's OpenGL 2.1 is perfectly within it's remit to not support any of the _ARB, _EXT, _NV, _ATI or whatever stuff. It's still a 100% conformant OpenGL 2.1 card even if it only supports the suffix-less versions of the entry points, although in practice this doesn't ever happen.
So which to use? I would probably lean towards checking each in the order: core (i.e. suffix-less), then _ARB, then give up. That ensures that you're getting the most correct and up to date version of the extension (and some of the older ones have really *weird* behaviour) but have a compatible fall-back in case you encounter an older driver. Another viable approach is to just check for _ARB and forget about the suffix-less versions, and I've also used this in the past. The most important thing is to be consistent, so if you're getting the entry points for any given extension, make certain that all the entry points you get for that extension are _ARB (or not, as appropriate). In theory it shouldn't matter but sometimes it does.
If all of this sounds like a horrible confusing mess (and it is), the good news is that there are libraries available - like GLEW - that will work it all out for you. So that's my final recommendation - grab a copy of GLEW and use that instead of checking extensions yourself.
Author
Quote:Original post by Dunge
Both non-extension and extension functions exists on every platforms, so you don't have to use them differently on one platform or another. Whether or not you can use them are limited by the video card hardware, not your OS.
That's not true Dunge, as I said in my post, I can't access the geometry shader in core on my windows vista, but I can access it through ARB, while on the Mac I can use geometry shader in core.
Quote:Original post by mhagain
If all of this sounds like a horrible confusing mess (and it is), the good news is that there are libraries available - like GLEW - that will work it all out for you. So that's my final recommendation - grab a copy of GLEW and use that instead of checking extensions yourself.
As I said in my post, I use GLee which is something similar to GLew afaik. But it gives me the choice to use both core and ARB versions (and you can check for support of them).
It is my intension to develop games only for the graphical hardware that supports everything my code needs. I don't want to support lower adapters.
So if I understand you correctly, I should then just check with GLee if the functions I will need are supported right at the beginning of my program and then start the game or immediately tell the user that his card is not supported.
Then, within the code, just to be safe, I can just always write code with the ARB suffix just to make sure that I have access to all of it (as I said, without ARB I can't access the geometry shader, with ARB, I can). That way, I will make sure that the code will work on all targeted platforms, even the very old ones like windows 98, when ran with a new enough video adapter (I don't know if that is even possible, running windows 98 with a new video adapter, I'm just trying to make a point of course)?
Am I right about these assumptions?
Quote:Original post by scippieYou are missing a key point however - the ARB and core versions are functionally identical. If your card doesn't have the functionality in core, but it does expose the extension, then GLee/GLew will bridge the core versions over to the extension versions, or vice-versa.
But it gives me the choice to use both core and ARB versions (and you can check for support of them).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
