Chapter 21 OpenGL I: The Independent
Compatibility Ladder

All four implement CNA directly. None routes through EasyGL, and none is an alias for an EasyGL profile. The apparently similar names therefore describe API eras, not modes of one code base.

OPENGL1 is available only on Linux or Windows and links the system OpenGL library. There is no shader stage to compile, cache, or bind. CNA state is translated into texture environment, matrix, lighting, fog, alpha, blend, depth, stencil, and client-array state that the fixed pipeline understands.

This is not equivalent to a 2D fallback. Both extended primitive entry points are native overrides and submit fixed-function geometry. A GpuDrawParams packet must be reduced to the subset expressible by the pipeline rather than silently falling through the base colored path. The result can draw 3D geometry, but custom programmable effects are an architectural impossibility, not a missing weekend task.

OPENGL2 is the transition renderer. Its context remains a compatibility-profile world, while vertex and fragment work is expressed as GLSL 1.10. That combination makes it materially different from both neighbours: it is programmable unlike OPENGL1, but cannot be served by EasyGL’s ES-oriented shader rewriting and profile macros.

The renderer owns real extended primitive paths, render targets, and effect-aware submission. Its optional ceiling again follows loaded functions rather than the name alone:

• •

  2D render targets are supported;

• •

  MRT is conditional on glDrawBuffers;

• •

  occlusion queries are conditional on query creation being available.

GLSL 1.10 also explains why shader source is an integration boundary. A shader written only for modern core GLSL cannot simply be handed to this renderer, and an ES shader is not made desktop-compatible merely by changing its version line. Attribute syntax, fragment outputs, precision qualifiers, and built-ins belong to the selected language profile.

OPENGLES1 targets libGLESv1_CM and GLES/gl.h. The dependency is not vendored, and the module refuses configuration when the system library is absent. Stock Mesa builds commonly disable GLES1, so the repository supplies a dedicated ES1-enabled Mesa environment script for this renderer’s evidence path.

Like OPENGL1, it has no shaders. Unlike OPENGL1, its API ceiling is the smaller ES 1.1 fixed-function surface. It implements 2D targets but neither MRT nor occlusion queries.

TINYGL fetches the pinned C-Chads TinyGL revision and renders a fixed-function OpenGL 1.x-style pipeline into its own CPU framebuffer. It owns ordinary and indexed extended draws, including colored, textured, colored-textured, normal-textured and skinned layouts. It reports only ThreeD and WireFrame among the graphics capabilities.

The single-context framebuffer is also the hard boundary: there is no FBO model, so RenderTarget2D, cube targets and MRT are unavailable; texture cubes, volume textures, occlusion queries, programmable effects, instancing, multi-stream input, MSAA and anisotropic filtering are refused. This is a real CPU 3D renderer, not the SOFTWARE family and not a native OpenGL context. The tag contains fourteen TinyGL suites with 113 named checks and a dedicated workflow; this edition records their presence rather than claiming a fresh workflow run.

The three families require different verification environments.

Registration totals are deliberately omitted here. They drift as cases are split or merged and do not measure assertion quality. The useful question is whether a test reaches a real context, submits pixels through the family-specific path, and observes the result.

Choose OPENGL1 only when fixed-function desktop compatibility is itself a goal. Choose OPENGL2 when GLSL 1.10 and compatibility contexts match the deployment target. Choose OPENGLES1 when the ES 1.1 environment is intentional and its fixed-function ceiling is acceptable. For a broader programmable profile set, continue with Chapter 22. Choose TINYGL when a CPU-only fixed pipeline is the intended deployment; a similar API surname does not erase the implementation boundary.

Before shipping on any of the four, verify four things on the target implementation:

1. 1.

   the selected identity reported at runtime is the one configured at build time;

2. 2.

   the render-target and query features actually used by the game are available;

3. 3.

   representative effect-aware draws retain their intended semantics rather than taking a reduced path;

4. 4.

   pixel evidence is collected from the real context, not only from a construction or no-throw smoke test.

That checklist is the recurring lesson of the compatibility ladder: an old API can implement a surprising amount of CNA, but its limits must be stated as limits of a particular path, not blurred into the capabilities of the OpenGL family as a whole.