Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I got interested in studying graphic programming so the obvious entry point was to learn OpenGL. But gathering scattered information around forums and sites, it seems that a pure OpenGL implementation is fading out since most things pre-3.0 are being deprecated and quoting a review on Amazon, "since 3.0 it's all about the shaders". Also of the books that I've seen, looks like only the superbible covers the newer version, but only partially because a good portion of the book teaches deprecated functions, and there are books specifically to GLSL.

This is where I ran into my first problem, some hardwares do not support GLSL, including the notebook with intel integrated graphics that I had planned on using. The function

GLuint vertShader = glCreateShader(GL_VERTEX_SHADER);

causes a segmentation fault and from the looks of it my driver does not support shaders

So my question is, what is the viability of making a game only in OpenGL? will I be missing irreplaceable good features from the shader language? And what kind of hardware (old gen i3, i5, i7, old VGAs) can I expect to run a game with shaders properly?

share|improve this question
    
GLSL is OpenGL, I think your question is related to whether the hardware you intend on using is OpenGL 3 compatible, not specifically GLSL compatible. –  Daniel Dec 22 '11 at 0:42
    
@Daniel so if a hardware/driver is OpenGL 3.0 compatible it is GLSL compatible? –  Papavoikos Dec 22 '11 at 0:45
1  
GLSL is part of the OpenGL 3.0 specification, so yes, that is the case. –  Daniel Dec 22 '11 at 0:58
1  
You say, "from the looks of it my driver does not support shaders." What version of OpenGL are you getting? Are you correctly loading all the available OpenGL functions? –  Nicol Bolas Dec 22 '11 at 1:05
1  
@Papavoikos: If it returns NULL, you've got much bigger problems than whether to use shaders. Are you creating your OpenGL context correctly? Remember: you can't call any GL functions until you have a valid context created and made current. –  Nicol Bolas Dec 22 '11 at 17:49
show 2 more comments

closed as off-topic by Vaughan Hilts, Anko, Josh Petrie Apr 8 at 16:16

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – Vaughan Hilts, Anko, Josh Petrie
If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

up vote 8 down vote accepted

Shader code is definitely clearer and easier to understand than a mess of glTexEnv, glTexGen and texture matrix calls, and has the bonus that you can express any more-or-less arbitrary math operation using it (which you can't do with the fixed pipeline - what you're calling "pure OpenGL"). The only potential downside is that you need to write a certain amount of supporting infrastructure in your code before you can begin to use them, whereas with the old way you can pretty much dive right in. I call that a "potential" downside because I actually think that it makes you prepare things and learn a little more in advance - OpenGL has a reputation for being "easy" and you occasionally do see people being fooled by this and diving right in without really knowing what they're doing first, which does not stand to their good in the longer term.

Hardware-wise you can rely on almost anything released in the past 5/6/7 years to have some degree of shader support, but - in the case of older Intels (some of the 9xx series) - it's not going to be GLSL, but will instead be the older GL_ARB_vertex_program and GL_ARB_fragment_program extensions. These use an assembly language-like shader language, but - confession time - I'm personally quite fond of it. It's actually quite easy to use, if lacking in some more modern features (such as branching) and requiring more lines of shader code to do the same thing. The supporting infrastructure required in your main program for these extensions is a lot more lightweight than for GLSL too.

That's not to say that I'd recommend them over GLSL however, but they are an option that is there if you really need to run on this class of hardware and it's useful to be aware that they exist, which brings me to the final point. Are you really certain that you really need to run on this class of hardware (e.g in the case of your notebook you may have just neglected to get the entry points)?

share|improve this answer
    
I completely neglected the fact that Mesa3d is still on opengl 2.1 specification. I'll fix that –  Papavoikos Dec 22 '11 at 11:38
add comment

If you've done any programming in the past, writing your own shader code using GLSL will be much more enjoyable. I originally tried learning fixed-function OpenGL and it was harder for me because it didn't make sense. Then I tried to learn GLSL using the orange book and it was much easier and made more since. Just my 2 cents.

I would definitely go towards GLSL because of the power to write programs for the GPU.

share|improve this answer
add comment

It should also be noted that there is no "pure OpenGL" anymore.

OpenGL ES 2.0 ditched all non-shader stuff, and since WebGL is based on it, it too only works with shaders. OpenGL 3.0 deprecated all of the fixed-function stuff, and 3.1 removed it (in core profiles. Most implementations support compatibility profiles, but MacOSX does not for their 3.2 implementation).

So I wouldn't suggest learning non-shader OpenGL.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.