API philosophy

The OpenGL API wrapped in OpenGL.Net are automatically generated from the GL specification. All commands, constants and enumerations are under the OpenGL namespace, scoped in the classes Gl, Wgl, Glx and Egl.

Multiple API, single namespace

All commands and enumeration can be shared by multiple API specifications. The entire set of commands and enumerations are effectively referenced by features, that are nothing but Khronos API specifications. Currently, OpenGL.Net implements:

• OpenGL
• OpenGL ES
• OpenGL SC

Function pointers are loaded depending on the current OpenGL context (or any specific API, really). Indeed, it should be possible to write common code for OpenGL 4.5 core profile and OpenGL ES 3.2; the evolution of the specifications lead to a common specification.

Command and enumeration naming guidelines

• All GL (and related) commands and constants have a prefix for indicating the API which they belong to. This prefix is removed during the code generation.
• In the case the command or the constant starts with a numeric character, the symbol is prefixed with an underscore (_) character.
• Commands can have a postfix indicating which kind of data takes as arguments (i.e. f or fv): the postfix is removed, taking the advantage of the method overloading offered by C#.
• In case when one or more parameters have an enumeration type, the signature with enumeration is preferred; the canonical signature is not generated (usually).
• Command parameters should follow the GL specification; in this way the parameter order, type and name are coherent with the specification.

As examples:

• glBegin(GL_POINTS) becomes Gl.Begin(PrimitiveType.Points)
• glVertex4f(x, y, z, w) becomes Gl.Vertex4(x, y, z, w)

Backward compatibility

Since the GL specification has the concept of command aliasing (equivalent commands); every command being an alias of another command will not be generated. Instance example: an actual call to glTexImage3DEXT is not possible if glTexImage3D is implemented; this is managed automatically by loading correct procedures.

This is a fundamental topic, since it is not possible to guarantee backward compatibility: the current OpenGL.Net API follows Khronos specification; if the alias information changes, then OpenGL.Net public API changes. However, not so many changes are expected during specification development (normally the changes happens after the promotion of EXT commands to ARB/KHR, or ARB/KHR to core, i.e. without any suffix).