   Is there a C++ wrapper for OpenGL?
  I've been working on my own set of functions for OpenGL to make programming with it simpler, like so:// Using a namespace to remove the gl prefix for every function.namespace glpp {// Starting with the vertex functions.void vertex( GLint   x, GLint   y ) { glVertex2i( x, y ); }void vertex( GLfloat x, GLfloat y ) { glVertex2f( x, y ); }void vertex( GLfloat x, GLfloat y, GLfloat z ) { glVertex3f( x, y, z ); }// Using array references to overload functions, too.void vertex( GLint (&v)[2] ) { glVertex2iv( v ); }void vertex( GLint (&v)[3] ) { glVertex3iv( v ); }} // namespace glppThe vertex overloads taking in array references are especially useful to me since my N-dimensional vector class has a function, data, that returns a reference to its internal array and that lets me write    vertex( v.data() );Is there a library that already does this? I've only been overloading functions as i need them, but it'd be nice if every glFunction was already done for me :).I didn't find much except this article, but it doesn't help with any function i'm using.   
  Wrapping glVertex and friends is a dead-end venture for a new, general purpose project, since those functions are deprecated. And all you've demonstrated here is really naive call-through functions. There are certainly libraries out that abstract OpenGL, but they tend to do it at a more useful level of abstraction.Your code appears to be adding very little value. You could be calling glVertex3iv with the result of this data() function just as easily, for example. The same is true of all those demonstrated methods.   ;Quote:Original post by jpetrieWrapping glVertex and friends is a dead-end venture for a new, general purpose project, since those functions are deprecated.This rises my eyebrow quite high! I haven't found any tutorials that show how to draw polygons without using the what-you-call-deprecated vertex functions. Does anyone have a link to one?Quote:There are certainly libraries out that abstract OpenGL, but they tend to do it at a more useful level of abstraction.I'm aware of those libraries, but i do not wish to abstract OpenGL, nor use a library that does. That would be counter-productive to learning OpenGL!Quote:Your code appears to be little more than an adapter for use with your own containers (which sound questionable since you could just be using a vector), so you probably won't find much else out there that is similar.If you are speaking of the array-reference vertex functions, no, they are not designed for my own containers. I originally was thinking using arrays in my drawing functions. This ended up working very well with the interface. The fact that my vector class' data function returns an array reference is not coincidental, but it's the vector class conforming to my gl abstraction, not the other way around.   ;Quote:Original post by Splinter of ChaosQuote:Original post by jpetrieWrapping glVertex and friends is a dead-end venture for a new, general purpose project, since those functions are deprecated.This rises my eyebrow quite high! I haven't found any tutorials that show how to draw polygons without using the what-you-call-deprecated vertex functions. Does anyone have a link to one?Immediate mode functions ('immediate mode' being the term for the type of per-vertex functions you're using) are often used in tutorials due to their simplicity, but I'm surprised you haven't come across any tutorials demonstrating other methods. Immediate mode was already an antiquated method a good 10 (?) years ago; at the very least, you should look into using vertex arrays (which, for what it's worth, aren't some arcane, undocumented feature - they're described in detail in the Red Book, for example).That said, it does seem to be the case that there's a dearth of good references and tutorials that show how to use modern techniques with OpenGL (e.g. programmable pipeline, etc.). Even if you have to target old hardware though, you should at least look into using vertex arrays.   ;Quote:If you are speaking of the array-reference vertex functions, no, they are not designed for my own containers. I originally was thinking using arrays in my drawing functions. This ended up working very well with the interface. The fact that my vector class' data function returns an array reference is not coincidental, but it's the vector class conforming to my gl abstraction, not the other way around.I misread your post initially and didn't realize you were referring to vectors-as-in-3D, et cetera. However that doesn't change the fact that you could just call glVertex3iv directly. All you're doing is (1) adding a namespace and (2) using overloads because they exist in C++ and not in C (which is why GL doesn't have them). While it may add some very, very small bit of value for you (although I question the point), as a product it is <completely useless, which is why you won't find much out there that does the same thing.;Quote:Original post by Splinter of ChaosQuote:Original post by jpetrieWrapping glVertex and friends is a dead-end venture for a new, general purpose project, since those functions are deprecated.This rises my eyebrow quite high! I haven't found any tutorials that show how to draw polygons without using the what-you-call-deprecated vertex functions. Does anyone have a link to one?Immediate mode functions (glVertex* and the like) were deprecated in OpenGL 3.0 and removed in 3.1. They have been replaced by vertex buffer objects - a simple google search on the term will reveal lots of tutorials.A simple, useful abstraction over OpenGL might look something like this:GraphicsDevice* device = new GraphicsDevice(context_handle);device->SetVSync(true);device->SetDepthTest(true);VertexBuffer* vbo = new VertexBuffer(device);vbo->SetData(vertices); // vertices is a vector of (generic) vertex structuresElementBuffer* ebo = new ElementBuffer(device);ebo->SetData(elements); // elements is a vector of ints or shortsShaderProgram* program = new ShaderProgram(device);program->Add(new VertexShader(device, "...")); // The second parameter is a char[] that contains the source codeprogram->Add(new FragmentShader(device, "..."));program->Link();device->SetElements(ebo);device->SetProgram(program);device->SetAttribute("Position", vbo, 0); // Last parameter is offset in bytes inside a single "vertex" elementdevice->SetAttribute("Normal", vbo, sizeof(vec3));device->SetAttribute("TexCoord", vbo, 2 * sizeof(vec3));device->SetUniform("Modelview", ...);device->SetUniform("Projection", ...);device->ApplyState();device->DrawElements(PrimitiveType::Triangles, 0, ebo->GetLength());Obviously, there's a lot more stuff to add (textures, framebuffers, renderbuffers, pixel buffers, vertex array objects, more shader types) but it's an interesting project that will teach you tons about OpenGL. However, make sure to build an actual application at the same time (demo, game, whatever). This will help you maintain perspective and distinguish between good and bad design decisions.Expect to make design mistakes: it's simply impossible to create a good abstraction without deep knowledge of the raw API first! As you gain in knowledge, you'll discover better/simpler/faster ways to achieve specific things. Don't hesitate to go back and improve the abstraction as necessary (and use source control so you can roll back at any point!)Finally, visit humus.name and check out the various OpenGL demos available under the 3d section. They are an invaluable source of information and his "frameworks" are almost exactly what you wish to implement - don't be afraid to use them as inspiration!Edit: removed a couple of C#-isms from the code (C++ doesn't have properties, duh!)   ;Quote:Original post by jykImmediate mode functions ('immediate mode' being the term for the type of per-vertex functions you're using) are often used in tutorials due to their simplicity, but I'm surprised you haven't come across any tutorials demonstrating other methods.Upon further research, i have, but vertex arrays are always marketed as an optimization, not a standard, which is the vibe i get from this discussion. Because of that, i always assumed they were unnecessary since my programs were fast enough already. (Premature optimization is the root of all what again?)I wonder if many other beginners used this logic. If so, and it is wrong, then perhaps that is a problem.Quote:Original post by FiddlerExpect to make design mistakes: it's simply impossible to create a good abstraction without deep knowledge of the raw API first! As you gain in knowledge, you'll discover better/simpler/faster ways to achieve specific things. Don't hesitate to go back and improve the abstraction as necessary (and use source control so you can roll back at any point!)Exactly! That's why i worked to wrap OpenGL in the first place. And only after i got the handle of it did i decide i should outsource that work.This shift of focus has made the article i linked in the first post more relevant. I'll work to implement my own wrapper still (I find the namespace incredibly useful, even if others may not.), but i still wonder if there's a library out there that does this for me.   ;Quote:I wonder if many other beginners used this logic. If so, and it is wrong, then perhaps that is a problem.This was one of the major criticisms of OpenGL up until they finally deprecated and removed the immediate mode methods: that the obvious path was the least optimal.   ;  Read about VBO (Vertex Buffer Object)http://www.opengl.org/wiki/General_OpenGLthere are some examples in therehttp://www.opengl.org/wiki/VBO_-_morehttp://www.opengl.org/wiki/VBO_-_just_examples   ;Quote:Upon further research, i have, but vertex arrays are always marketed as an optimization, not a standard, which is the vibe i get from this discussion. Because of that, i always assumed they were unnecessary since my programs were fast enough already. (Premature optimization is the root of all what again?)Sure - all other things being equal, if immediate mode is fast enough for your application, vertex arrays (or VBOs, etc.) aren't needed. Something like Tetris, for example, would almost certainly get by just fine with immediate mode.The problem though is that as a technology, immediate mode (and more generally the fixed-function pipeline) really is on its way out. I'm not an expert on graphics hardware, but my understanding is that most modern hardware doesn't even support the fixed-function pipeline natively (it's simply emulated using the programmable pipeline). In the (near?) future, I imagine it may even be the case that some cards won't support the fixed-function pipeline at all. The fact that this functionality has been removed entirely in the latest version of OpenGL is also worth noting.In some ways, working with the programmable pipeline is actually easier than working with the fixed-function pipeline, IMO. However, it's true (I think) that getting a single triangle onscreen requires a lot more boilerplate code using modern techniques than using the FFP and immediate mode. This is probably one of the reasons why the latter continues to appeal to developers, and also why tools that provide a degree of abstraction from the underlying API (e.g. Unity, Ogre, etc.) are becoming increasingly popular.   