Opengl Q & A / Faq
by Alex Scarborough · in General Discussion · 07/26/2006 (2:02 am) · 21 replies
It seems that there are some misconceptions about OpenGL and what it can do that are floating around the internet. There always will be, of course, but I'd like to do what I can to keep the GarageGames community properly informed. Discussion of OpenGL is especially pertinent to anyone who has wanted to, or does currently want to, improve the TGE rendering system, and that seems to be a popular thing to do lately. Also, after so many threads that are people asking questions, won't it be nice to have a thread dedicated to giving answers?
Simply post any questions you may have about OpenGL, and I will do my best to answer them. If someone else has an answer, that's awesome! Post it! I'll try and keep this file updated with a full set of all questions and answers, and will hopefully turn it into a TDN article if it becomes worthwhile as one.
I will not answer some questions that can be easily googled. For example "How do I draw a triangle?". I will answer questions such as "What is the best way to render: glDrawArrays or glDrawElements?", "What do vertex buffer objects really do?" or "The 183 page specification for GL_EXT_framebuffer_object is terrifying. I just want to set up a simple render to texture in OpenGL. Can you give an example of how to do this, explaining the various limitations of the extension in a way that mere mortals can comprehend?" Questions along the lines of "Can OpenGL do?" are also acceptable. If you have a question specific to how Torque uses OpenGL, feel free to email me. If there are a lot of questions specific to how Torque uses OpenGL, I may start a similar thread in the private forums.
On a final note, please do not get this thread off track. Do not turn it into a flame war over D3D vs. OpenGL. In fact, I will not answer "Which is better, OpenGL or D3D?". That's a decision you have to make yourself based on your target audience, what your game requires, what you know, and what you are willing to learn.
Here's a start.
Q1: What is OpenGL?
A1: OpenGL is an open source crossplatform API for hardware accelerated rendering of 2D and 3D images.
Q2: Who controls OpenGL?
A2: OpenGL is currently controlled by the Architecture Review Board (ARB) which is composed of representatives from numerous corporations including IBM, 3Dlabs, SGI, Apple, ATI, NVIDIA, Microsoft, and Intel. However, by the end of this year, the ARB will merge with the Khronos group, creators of OpenGL ES and the Collada file format.
Q3: Why would I want to use OpenGL?
A3: There are numerous reasons you would want to use OpenGL in your game. OpenGL is the only crossplatform 3D graphics API, so if you need/want Mac or Linux support, OpenGL is the way to go.
Many people find OpenGL easier to use than Direct3D.
OpenGL has far better support for legacy code than Direct3D (in fact, code written for OpenGL 1.0 works fine with the OpenGL 2.0 headers).
In SOME cases, OpenGL may be faster than Direct3D for your game.
Simply post any questions you may have about OpenGL, and I will do my best to answer them. If someone else has an answer, that's awesome! Post it! I'll try and keep this file updated with a full set of all questions and answers, and will hopefully turn it into a TDN article if it becomes worthwhile as one.
I will not answer some questions that can be easily googled. For example "How do I draw a triangle?". I will answer questions such as "What is the best way to render: glDrawArrays or glDrawElements?", "What do vertex buffer objects really do?" or "The 183 page specification for GL_EXT_framebuffer_object is terrifying. I just want to set up a simple render to texture in OpenGL. Can you give an example of how to do this, explaining the various limitations of the extension in a way that mere mortals can comprehend?" Questions along the lines of "Can OpenGL do
On a final note, please do not get this thread off track. Do not turn it into a flame war over D3D vs. OpenGL. In fact, I will not answer "Which is better, OpenGL or D3D?". That's a decision you have to make yourself based on your target audience, what your game requires, what you know, and what you are willing to learn.
Here's a start.
Q1: What is OpenGL?
A1: OpenGL is an open source crossplatform API for hardware accelerated rendering of 2D and 3D images.
Q2: Who controls OpenGL?
A2: OpenGL is currently controlled by the Architecture Review Board (ARB) which is composed of representatives from numerous corporations including IBM, 3Dlabs, SGI, Apple, ATI, NVIDIA, Microsoft, and Intel. However, by the end of this year, the ARB will merge with the Khronos group, creators of OpenGL ES and the Collada file format.
Q3: Why would I want to use OpenGL?
A3: There are numerous reasons you would want to use OpenGL in your game. OpenGL is the only crossplatform 3D graphics API, so if you need/want Mac or Linux support, OpenGL is the way to go.
Many people find OpenGL easier to use than Direct3D.
OpenGL has far better support for legacy code than Direct3D (in fact, code written for OpenGL 1.0 works fine with the OpenGL 2.0 headers).
In SOME cases, OpenGL may be faster than Direct3D for your game.
About the author
#2
That's a slight understatement in my opinion.
I and many developers I know have forwarded issues to ATI and always receive a very disinterested response.
ATI isn't exactly world renowned for its driver quality and continues their long history of half-assed OpenGL support.
I remember when Doom3 was in early development and it exposed so many bugs in ATI's drivers that John Carmack shunned the company for six months. It seems that only a major developer with a lot of influence over what graphics cards people buy can get ATI to actually care about their driver quality. I wish there was some recourse for everyone who isn't Id Software.
One shouldn't have to go to these extreme measures:
Click
Nice post by the way Alex, sorry if this post is off track.
- Tim
07/26/2006 (5:46 am)
Quote:
ATI's OpenGL support is currently a bit behind, but that may change.
That's a slight understatement in my opinion.
I and many developers I know have forwarded issues to ATI and always receive a very disinterested response.
ATI isn't exactly world renowned for its driver quality and continues their long history of half-assed OpenGL support.
I remember when Doom3 was in early development and it exposed so many bugs in ATI's drivers that John Carmack shunned the company for six months. It seems that only a major developer with a lot of influence over what graphics cards people buy can get ATI to actually care about their driver quality. I wish there was some recourse for everyone who isn't Id Software.
One shouldn't have to go to these extreme measures:
Click
Nice post by the way Alex, sorry if this post is off track.
- Tim
#3
Should that not be "3D graphics API", or "most prominent graphics API" as there are a few other 2D graphics APIs out there that are equally cross platform.
07/26/2006 (6:04 am)
"OpenGL is the only crossplatform graphics API, so if you need/want Mac or Linux support, OpenGL is the way to go."Should that not be "3D graphics API", or "most prominent graphics API" as there are a few other 2D graphics APIs out there that are equally cross platform.
#4
@Ian: Changed it. Out of curiosity though, can those APIs use the GPU? If not I may change it to "hardware accelerated graphics API".
07/26/2006 (9:57 am)
@Tim: I actually have a blog post about how horrible ATI's OpenGL support is. I've been having my own fun uphill battles with that.@Ian: Changed it. Out of curiosity though, can those APIs use the GPU? If not I may change it to "hardware accelerated graphics API".
#5
they are my target machine.
I have developed an engine here at work that use's OpenGL while not having all the wizz bang features.
the basic support is complete and robust enough to make many game genres on.
you need to maybe double check what version of gl they support. it is not that far behind that it would be considered "terrible"
07/26/2006 (10:08 am)
I would like to stick up for the intel cards.they are my target machine.
I have developed an engine here at work that use's OpenGL while not having all the wizz bang features.
the basic support is complete and robust enough to make many game genres on.
you need to maybe double check what version of gl they support. it is not that far behind that it would be considered "terrible"
#6
07/26/2006 (10:10 am)
So what are the most distinct differences between opengl and directX...other than support and portability?
#7
@Sean H. : I can answer that within a certain degree. I am not a DirectX expert, so if anyone who does have extensive experience with DirectX sees something wrong in here, correct me please.
First off, DirectX is not a graphics API, that would be Direct3D. DirectX also handles other things such as audio, networking, and input.
Narrowed down to Direct3D compared to OpenGL, here are some differences.
1) OpenGL is a function based system. glEnable(), glDrawElements(), glFramebufferRenderbufferEXT(), glUseProgram() etc. D3D on the other hand uses a more C++ style method. You create a D3DDevice, and then commands are issued in the form mD3D->setRenderState(), mD3D->setTexture(), mD3D->drawPrimitive() etc.
On a deeper level, this means OpenGL manages the state machine implicitly. A context is made active through whatever platform dependent function makes the context active, and then any gl functions implicitly modify that context. In D3D on the other hand you explicitly modify the D3DDevice.
If you own a copy of TSE, look at how GFX calls are made. D3D works in pretty much the same way.
2) Legacy support. D3D quickly deprecates functionality. Code written using D3D8 will not compile linked against D3D9, and chances are many changes would have to made to it to make it work under D3D9. OpenGL on the other hand has never officially deprecated functionality. Therefore, there are numerous different ways to do everything under OpenGL, while D3D generally has one or two set paths that are guaranteed to work.
3) Rendering pipeline efficiency. D3D draw calls are expensive. GL draw calls are significantly less expensive.
4) Flexibility. Everything in OpenGL is designed to do more than what it was meant for. For example, the GL_ARB_occlusion_query extension just implements occlusion queries, but also provides a basic interface for other kinds of queries. This interface is used in GL_EXT_timer_query. Similarly, GL_ARB_vertex_buffer_object provides a generic buffer management system, but only provides the hooks to use it for vertex (ish) data. GL_ARB_pixel_buffer_object adds in hooks to the buffer management system introduced in GL_ARB_vertex_buffer_object to use buffers for pixel data.
The same applies for things like GLSL shaders. The GL_ARB_vertex_shader and GL_ARB_shader_objects extensions are monstrous beasts that introduce dozens upon dozens of new methods and tokens. GL_ARB_fragment_shader on the other hand introduces three new tokens and no new methods, by using the interface created by GL_ARB_vertex_shader and GL_ARB_shader_objects.
To my knowledge, things in D3D do not work like this. Vertex shaders and Pixel shaders have their own very distinct pipelines in D3D, while in OpenGL, the only distinction made between vertex and pixel is made when the shader is first created. After that, it makes no difference whether or not it is a vertex or pixel shader.
5) New feature support. D3D almost always has the latest and greatest before OpenGL, and in some cases OpenGL can take years to catch up (see render-to-texture support in OpenGL for an excellent example of how absurd this can get).
Those are some of the big differences that come to mind at the moment. If anyone wants to add to this list, go ahead.
07/26/2006 (11:35 am)
@Badguy: If you like, I could say that intel cards have horrible support for the current version of OpenGL. Lack of GLSL shaders on shader capable hardware is a pretty nasty issue, and most people probably don't want to write ASM shaders or deal with Cg just for Intel cards.@Sean H. : I can answer that within a certain degree. I am not a DirectX expert, so if anyone who does have extensive experience with DirectX sees something wrong in here, correct me please.
First off, DirectX is not a graphics API, that would be Direct3D. DirectX also handles other things such as audio, networking, and input.
Narrowed down to Direct3D compared to OpenGL, here are some differences.
1) OpenGL is a function based system. glEnable(), glDrawElements(), glFramebufferRenderbufferEXT(), glUseProgram() etc. D3D on the other hand uses a more C++ style method. You create a D3DDevice, and then commands are issued in the form mD3D->setRenderState(), mD3D->setTexture(), mD3D->drawPrimitive() etc.
On a deeper level, this means OpenGL manages the state machine implicitly. A context is made active through whatever platform dependent function makes the context active, and then any gl functions implicitly modify that context. In D3D on the other hand you explicitly modify the D3DDevice.
If you own a copy of TSE, look at how GFX calls are made. D3D works in pretty much the same way.
2) Legacy support. D3D quickly deprecates functionality. Code written using D3D8 will not compile linked against D3D9, and chances are many changes would have to made to it to make it work under D3D9. OpenGL on the other hand has never officially deprecated functionality. Therefore, there are numerous different ways to do everything under OpenGL, while D3D generally has one or two set paths that are guaranteed to work.
3) Rendering pipeline efficiency. D3D draw calls are expensive. GL draw calls are significantly less expensive.
4) Flexibility. Everything in OpenGL is designed to do more than what it was meant for. For example, the GL_ARB_occlusion_query extension just implements occlusion queries, but also provides a basic interface for other kinds of queries. This interface is used in GL_EXT_timer_query. Similarly, GL_ARB_vertex_buffer_object provides a generic buffer management system, but only provides the hooks to use it for vertex (ish) data. GL_ARB_pixel_buffer_object adds in hooks to the buffer management system introduced in GL_ARB_vertex_buffer_object to use buffers for pixel data.
The same applies for things like GLSL shaders. The GL_ARB_vertex_shader and GL_ARB_shader_objects extensions are monstrous beasts that introduce dozens upon dozens of new methods and tokens. GL_ARB_fragment_shader on the other hand introduces three new tokens and no new methods, by using the interface created by GL_ARB_vertex_shader and GL_ARB_shader_objects.
To my knowledge, things in D3D do not work like this. Vertex shaders and Pixel shaders have their own very distinct pipelines in D3D, while in OpenGL, the only distinction made between vertex and pixel is made when the shader is first created. After that, it makes no difference whether or not it is a vertex or pixel shader.
5) New feature support. D3D almost always has the latest and greatest before OpenGL, and in some cases OpenGL can take years to catch up (see render-to-texture support in OpenGL for an excellent example of how absurd this can get).
Those are some of the big differences that come to mind at the moment. If anyone wants to add to this list, go ahead.
#8
this is where I pointed out it does not include all the wizzbang features.
however, shaders do not make up the api.
I would state that it is not terrible as the fixed function pipeline is fully operational.
compared for example to OpenGL ES where many features have been removed from OpenGL to enable mobile device support.
the intel card family supports at least version 1.3 of OpenGL. ..that is not terrible.
so if this is to be an OpenGL faq, the focus should not be on shaders and anything that dont support them is terrible.
you will find the d3d support on those cards just as lacking.
07/26/2006 (12:05 pm)
Well honestly.this is where I pointed out it does not include all the wizzbang features.
however, shaders do not make up the api.
I would state that it is not terrible as the fixed function pipeline is fully operational.
compared for example to OpenGL ES where many features have been removed from OpenGL to enable mobile device support.
the intel card family supports at least version 1.3 of OpenGL. ..that is not terrible.
so if this is to be an OpenGL faq, the focus should not be on shaders and anything that dont support them is terrible.
you will find the d3d support on those cards just as lacking.
#9
Intel drivers also tend to have buggy OpenGL support, especially if they aren't updated. This isn't true in all cases (nothing is) but it is worth pointing out, and it is something that people should keep in mind when deciding if they want to use OpenGL or D3D. D3D Intel drivers are generally far more stable and complete.
I'm not saying shaders are everything. I am saying that when the hardware supports a feature but the driver doesn't, then there is a support issue.
But now we're getting off track. I'll change it to say that support for the CURRENT version of OpenGL is lacking.
07/26/2006 (12:21 pm)
@Badguy: My issue with Intel cards is not the hardware, it is the drivers. Let me put this point blank: GLSL is supported on intel cards, if you're using a Mac. GL_EXT_framebuffer_object is supported on intel cards, if you're using a mac. GL_ARB_rectangle_texture is supported on intel cards, if you're using a mac. The underlying hardware is identical, the only difference is the driver. To me, that says OpenGL support on Intel cards under Windows is pretty bad.Intel drivers also tend to have buggy OpenGL support, especially if they aren't updated. This isn't true in all cases (nothing is) but it is worth pointing out, and it is something that people should keep in mind when deciding if they want to use OpenGL or D3D. D3D Intel drivers are generally far more stable and complete.
I'm not saying shaders are everything. I am saying that when the hardware supports a feature but the driver doesn't, then there is a support issue.
But now we're getting off track. I'll change it to say that support for the CURRENT version of OpenGL is lacking.
#10
Could you write down all your knowledge on OpenGL and e-mail it to me? :-) OR just point me to a good book?
07/27/2006 (12:09 am)
My Question:Could you write down all your knowledge on OpenGL and e-mail it to me? :-) OR just point me to a good book?
#11
The OpenGL RedBook is another excellent book, and was written by the ARB. It covers OpenGL in depth. It is full of very interesting code snippits and tidbits of information about OpenGL. In fact, the depth of field effect used in Day of Defeat: Source is explained in this book (it's about a dozen lines of code).
Also check out OpenGL.org the official OpenGL site. Futhermore, the ARB is currently working on an official OpenGL SDK, so keep your eyes peeled for more information about that.
Other good OpenGL tutorial sites are NeHe and CodeSampler.
Is that enough info to get you started?
07/27/2006 (12:22 am)
The OpenGL SuperBible is an excellent book that covers everything from the basics of OpenGL to the latest features such as GLSL shaders and vertex buffer objects.The OpenGL RedBook is another excellent book, and was written by the ARB. It covers OpenGL in depth. It is full of very interesting code snippits and tidbits of information about OpenGL. In fact, the depth of field effect used in Day of Defeat: Source is explained in this book (it's about a dozen lines of code).
Also check out OpenGL.org the official OpenGL site. Futhermore, the ARB is currently working on an official OpenGL SDK, so keep your eyes peeled for more information about that.
Other good OpenGL tutorial sites are NeHe and CodeSampler.
Is that enough info to get you started?
#12
The OpenGL Extensions Guide is a MUST have for anyone working with OpenGL. I'm surprised Alex didn't mention it.
07/27/2006 (12:39 am)
Quote:
OR just point me to a good book?
The OpenGL Extensions Guide is a MUST have for anyone working with OpenGL. I'm surprised Alex didn't mention it.
#13
07/27/2006 (12:53 am)
I considered it, but it's a book to pick up *after* you know OpenGL, not to *learn* OpenGL. I will add it to the answer in the text document, which I'm currently updating to a nice HTML doc.
#16
Thank you for that. It doesn't suck, these forums need more of these helpful posts. Thank you for your contributions!
07/27/2006 (5:46 am)
Quote:
They have been added to the HTML doc available here. Oh, and I used an HTML exporter for this. Please don't hurt me if it sucks.
Thank you for that. It doesn't suck, these forums need more of these helpful posts. Thank you for your contributions!
#17
I'm no authority on the subject, but this is incorrect. directx provides basic functionality for creating a context and rendering 2d layered surfaces in software in addition to sound, input, and networking. I know because ive written a few 2d apps in directx awhile ago while reading "windows game programming for dummies". granted, in this instance I did mean to say direct3d. : ) thanks for the useful info. I actually know a bit more about direct3d than opengl, but I've never written anything using either the api's directly and hopefully I'll never have to.
07/27/2006 (6:58 am)
"First off, DirectX is not a graphics API, that would be Direct3D. "I'm no authority on the subject, but this is incorrect. directx provides basic functionality for creating a context and rendering 2d layered surfaces in software in addition to sound, input, and networking. I know because ive written a few 2d apps in directx awhile ago while reading "windows game programming for dummies". granted, in this instance I did mean to say direct3d. : ) thanks for the useful info. I actually know a bit more about direct3d than opengl, but I've never written anything using either the api's directly and hopefully I'll never have to.
#18
07/27/2006 (8:21 am)
Would it be more appropriate to say that DirectX is not a 3D graphics API? As stated, I'm no expert when it comes to DirectX or Direct3D, being a mac guy and all that, so any corrections are welcome.
#19
on another note, I *really* like this thread. its nice to get information from experienced developeres and be able to ask them questions directly rather than reading some tutorial without being able to talk to the author. there should be more threads like this. I have a request. could someone start one of these about shaders? i know thats one area lots of newbies would benefit learning about. background and implementation information would be nice, but I would personally like to know more about the differences between cg, glsl, and hlsl and what factors one should consider when deciding which one to use/learn.
07/27/2006 (8:48 am)
I believe that would be accurate Alex. although IMO the term "directx" should be considered a general term referring to all modules under the directx umbrella; directplay, directsound, direct3d, etc. direct3d is a part of the directx technology, not a separate technology.on another note, I *really* like this thread. its nice to get information from experienced developeres and be able to ask them questions directly rather than reading some tutorial without being able to talk to the author. there should be more threads like this. I have a request. could someone start one of these about shaders? i know thats one area lots of newbies would benefit learning about. background and implementation information would be nice, but I would personally like to know more about the differences between cg, glsl, and hlsl and what factors one should consider when deciding which one to use/learn.
#20
Beyond that my knowledge of shaders is pretty solid. Actually, right now I'm working on an SM 1.1-1.4 refraction shader, which is... interesting, to say the least. It's interesting trying to juggle four texture reads when you only have six registers to use.
And yes, I agree, DirectX should be an umbrella term, but I've seen way too many DirectX fan boys bash OpenGL on the grounds that it doesn't handle sound or input, etc. whenever anyone asks for a comparison between DirectX and OpenGL. So, I decided to specify.
Edit: Shader QA/FAQ
07/27/2006 (9:07 am)
Sean H: I'll try and get a shader thread up sometime today. I can't claim to be an expert on the fine details of how HLSL works, but it's close enough to Cg that it fools the Cg compiler, so...Beyond that my knowledge of shaders is pretty solid. Actually, right now I'm working on an SM 1.1-1.4 refraction shader, which is... interesting, to say the least. It's interesting trying to juggle four texture reads when you only have six registers to use.
And yes, I agree, DirectX should be an umbrella term, but I've seen way too many DirectX fan boys bash OpenGL on the grounds that it doesn't handle sound or input, etc. whenever anyone asks for a comparison between DirectX and OpenGL. So, I decided to specify.
Edit: Shader QA/FAQ
Associate Alex Scarborough
A4: OpenGL driver support can be poor on Windows computers, and Intel Integrated cards, which make up a very large portion of existing GPUs, do not support the latest version of OpenGL (they are most notably missing GLSL shaders and render to texture support in the driver).
OpenGL's legacy support may make it difficult to determine what the best way to do things is, because every way that has ever worked still works. (there are four different calls that will render geometry in OpenGL, each with its own little quirks).
OpenGL has been historically slow to adjust to change in available hardware features.
ATI's OpenGL support is currently a bit behind, but that may change.
OpenGL is undergoing a complete rewrite (for real this time, they aren't going to chicken out) so you may find that everything you just learned is suddenly obsolete.
Q5: What are extensions?
A5: Extensions are just that: extensions to the OpenGL specification. They are used to add features to the specification that may not be supported by all GPUs, or when the ARB wants to add functionality to OpenGL without making it part of the core OpenGL specification just yet. Virtually all OpenGL features started as extensions, and many still are extensions. If you are D3D developer, you may find it easier to think of extensions as the OpenGL version of D3D's caps bits.
Extensions can be vendor specific (for example, GL_NV_fragment_program is only implemented on nVidia cards) or cross vendor (GL_ARB_fragment_shader is a good example of this). Be warned, just because the extension is approved by the ARB does not mean it is cross vendor. GL_ARB_pixel_buffer_object is an ARB extension, but it is not implemented on ATI cards.
Fire away!