Quote Originally Posted by Alfonse Reinheart
And what about "pre-tessellation hardware" that cannot actually implement transform_feedback2? Your problem is that you believe that this functionality is purely an API change. It is not.
This is basically my problem. I assumed that it is fully hardware implementable without "newer" tessellation hardware. I thought it is some kind cure to the problem of not having ARB_draw_indirect on OpenGL 3.x compatible hardware... Ok, I see my problem now.

Quote Originally Posted by Alfonse Reinheart
I don't see why you're so up in arms about things like transform_feedback_2, when there are far more eggregious pieces of functionality that could be implemented on GL 3.3 hardware that aren't core 3.3. Like ARB_separate_shader_objects, most of ARB_enhanced_layouts, ARB_explicit_uniform_locations, ARB_texture_storage, ARB_buffer_storage, and so forth. None of them are specific to hardware versions.
Because I implemented an algorithm that mainly uses transform_feedback_2 for computation and I was in the believe that the algorithm could run on older hardware that barely supports OpenGL 3.3 but not OpenGL 4. I was wrong as I was wrong about the OpenGL ES 3 thoughts. I didn't looked it up exactly enough.

Quote Originally Posted by Alfonse Reinheart
I wouldn't specify an OpenGL version. I would specific the specific hardware that I know will work. Like GeForce GT 2xx or better, Radeon HD 3xxx or better, Intel HD 4xxx or better. Not only is that more specific, it's easier for a user to know when they have the right hardware. They don't have to look up a version number; they just look up what their hardware is.
But that requires the user to check if her graphics card is newer than the one you specified and it requires you, the developer, to check if the driver actually implements that feature for all those graphics cards. Maybe I am wrong about that too, but if I read, "this graphics card is compatible to DirectX 11", can I assume that this graphics card supports ALL DirectX 11 features as a consumer as well as a developer? So could I equally say that "this product requires Core OpenGL 3.3", everyone can assume ALL features being implemented in the driver that can be look up in glcorearb.h, up to the specific section in that file?

Quote Originally Posted by Alfonse Reinheart
It's important to note that "written against" and "minimal version" are not always the same version number. For example, transform_feedback2 is written against OpenGL 2.1, so all of its changes are relative to that specification. But the minimum version it says that it requires is 2.0.
This is very confusing and I assume that I can not derive any association to core features from the raw spec files?!

Quote Originally Posted by Alfonse Reinheart
If you want to prevent such mistakes in the future, you should use an OpenGL Loading Library that provides version-specific loaders. Where you can say "only give me what core OpenGL 3.3 provides", and the headers you get will only have core functions from that version.
I would like to cut out some dependencies from my engine, so the gl loading has fallen first. Even if it means that I make mistakes. To be perfectly honest, only because we have Unity or UE doesn't mean the world has to stop coding OpenGL, C++ or anything else that is fun.