[exDM69]

I disagree with you.

OpenGL is a C api, so it's very natural to write introductory material for GL in C. Anyone is serious about wanting to use OpenGL should know enough C to read it and translate to whatever language you want. You also don't need to worry that much about language bindings or windowing system wrappers in the example apps. Example apps will also be more portable when written in C.

If this were written in Java, where there are no raw pointers or pointer arithmetic, etc, you'd have to use something like Java NIO Buffers or other abominations like that. You have to use raw pointers with OpenGL, since you do DMA transfers to upload and download geometry and texture data to and from the GPU. This is done with explicit transfer calls (with a pointer to the data) or with memory maps (where you get a pointer to a page aligned buffer that's ready for DMA transfer).

This is just another example on how every language that doesn't allow you to use pointers (for "security" reasons) will have something more complicated to replace them.

NOTE: if you really want Java versions, you can go ahead and write them. 10 years ago many people used the NeHe tutorials to learn OpenGL (don't touch them in 2011) and they were ported to pretty much any language and windowing framework out there. But they were ported bu individuals in the community, not by the original author.

[Klinky]

I'll disagree with you as well.

Just because it's a C API doesn't mean it isn't used in other languages or has to be used in C. C can be unforgiving on the novice, so battling C while trying to learn OpenGL concepts can quickly become a losing battle. Portability is at the cost of complexity, setting up a C/C++ OpenGL cross platform build environment is not a piece of cake, especially on Windows.

C does allow low level access to memory, while this is powerful it also adds complexity. Things like loading a text file or image file aren't straightforward. Many libraries are in various states of disrepair. Getting a crash course in static vs dynamic libraries, linker settings, dependency/DLL hell detracts greatly from the learning experience.

Suggesting that allowing the programmer to use a buffer object or array in a call to GLBufferData would be somehow more complicated than wrangling with pointers & memory allocation is something I'll have to firmly disagree on.

I'd honestly suggest someone starting out with OpenGL to try out WebGL. Loading shaders & textures is a snap(comparatively) & your build environment is your web browser & with that you get instant feedback. Javascript debuggers have also come a long way. Then later you can transfer your knowledge to other more performance oriented languages, if you need that.

[exDM69]

Thanks for disagreeing with style!

Even if a novice reader is not familiar with C at a very deep level, it's not that different from other programming languages. You should be able to read C and grasp the basic concepts of storing objects in memory, because a lot of OpenGL is about storing stuff in memory and you have to think about pointer alignments and stuff like that.

And besides, if you're writing example applications for a book or a tutorial, you should probably stick to very simple C code anyways. The kind that anyone can read to some degree.

Please note that I did not advocate that the reader must write their own projects using C, even if the book examples are in C. They can pick any other language they feel comfortable in. Just be prepared to deal with binding libraries and windowing toolkits and all the little things that you need.

Programming the GPU is one of the most hostile programming environments out there. You might not have a debugger available and you can't even debug with prints, you have to deal with memory explictly, drivers are buggy and a small mistake in your program might crash your computer partially or fully or cause very unintended consequences. I would not recommend for a novice who can't deal with C code to go there. This is true whether you use C or not. Even with WebGL.

Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming. Then it's actually better to take a 3d engine that deals with 3d models, lights and cameras and stay away from OpenGL, which is basically a very complicated way of drawing triangles very fast.

A lot of stuff you said about C being difficult in practice, libs that are broken, difficulty on setting up on Windows, etc are true. However, they don't really apply to using it as a language in programming examples in a book or a tutorial.

[willyt]

> Most of the people who want to learn OpenGL, actually want to learn 3d graphics programming.

What 3D engines would you recommend? I've looked at OpenInventor and Coin3d briefly but I'm interested in solid modelling as well, rather than 'just' visualisation. I'm guessing there's no such thing as an well documented and easy to use open source equivalent of the Parasolid or ACIS kernels? :-)

[NickPollard]

>> C can be unforgiving on the novice, so battling C while trying to learn OpenGL concepts can quickly become a losing battle.

Maybe this will be controversial, but OpenGL probably isn't something a novice programmer should be tackling.

[Klinky]

Maybe I should have said "C novice". There are many savvy programmers who have only glanced at C/C++ code or have never touched the thing. C can be a bit of a culture shock when coming from a dynamic or managed language.

[TillE]

I don't think it's unreasonable to say that basic familiarity with C is a prerequisite to low-level graphics programming.

There's no time like the present to expand your knowledge. If you can't read C or assembly, you're missing out on quite a lot.

[wtracy]

>>C does allow low level access to memory, while this is powerful it also adds complexity.

This low-level interaction with memory is pervasive in OpenGL's design. These features are so intrinsic to how OpenGL works that no wrapper can completely abstract them away.