OpenGL Games Programming and the Specification
Sections
Rasterisation of Primitive Types
A number of conformance test suites exist for use by licensed OpenGL implementations.
On Windows, WHQL certification requires that a driver pass the "mustpass" test, and all but a small number of the remaining "conform" tests. Windows drivers included in the GLSetup package should all be WHQL certified, as well as having been informally "checked for stability" by a large number of users of the package.
Note that passing the conformance tests does not guarantee that a driver will be completely bug free.
Note also that the open source clone of OpenGL, Mesa, is tested using the OpenGL conformance tests under a "special dispensation", although it is not a licensed OpenGL implementation.
An open source package for conformance testing is in development, and currently runs on X and Win32; see the Glean site.
Here are some tips on ensuring that an OpenGL application behaves correctly.
Note that although the formal specification for OpenGL describes an order in which operations such as z buffering and lighting should be done, it does not require that implementations actually use that order. It merely requires that the results of rendering with an implementation be indistinguishable from the results of rendering via the specified path. In practice, some implementations may execute operations in a different order to the one described for the sake of greater optimisation.
One of the original design goals of OpenGL was to enable remote rendering over a network, where the application is on one machine and the actual rendering hardware on another. While this is obviously not relevant to realtime 3d games, the distinction is still present in the terminology. Functions like glEnableClientState, for example, refer specifically to the state on the client. Where games targets are concerned, it may be reasonable to think of the client state as the state directly manipulated by the game code, while the server state belongs to the driver and rendering hardware.
Rasterisation of Primitive Types
It is worth remembering that when a quad or quad strip is split during clipping, there can be ambiguities as to how the resultant primitives are produced. This issue can introduce unusual visual effects when e.g. quads with vertex colours are clipped. In general, it is probably advisable to stick to triangles (and triangle strips and fans), rather than quads and quad strips, when rendering.
Note that calling glGetError within a glBegin / glEnd pair is itself illegal, and will generate an error.
The predecessor to OpenGL was an SGI proprietary library called IRIS GL. If you are trying to use pieces of IRIS GL code, here are some notes on converting IRIS GL to OpenGL programs, and here is a link to a library which can be used to run IRIS GL programs on an OpenGL driver in emulation.
SGI maintain a "reference implementation" of the current OpenGL specification. This is used as the basis for the vast majority of IHV drivers, e.g. through the Microsoft supplied but SGI written OpenGL DDK for Windows.
Source code for the reference implementation is freely available, under this source code license. Game writers may find it useful to have the source code available, to resolve any questions as to how implementations are supposed to behave or to get some feel for what areas of a driver might be expected to be heavily optimised.
It should be noted, however, that as of January 2000 this source code release does not contain every code component which an IHV might be expected to have. For example, it includes no source code for any hardware accelerated driver, or for the runtime optimised assembler rasterisation code used in e.g. SGI's OpenGL for Windows (see the Windows support area). It also does not include the optimised geometry pipeline code available as part of the Windows DDK, due to licensing conflicts with companies such as Intel who supplied the actual assembly code involved. A FAQ giving more detail about the release is available online.
The release should contain enough code to build a complete, but not especially fast, software version of the current OpenGL, glu and glX specifications on an X-Windows system. In a sense, it is similar to the "refrast" reference driver provided as part of Direct3D, except that the source code for the sample implementation is publically available, whereas only the binary can be obtained for refrast.