In the world of gaming, SDL provides the entire necessary infrastructure. This would have become clear from previous articles in this series. Infrastructure is to a game what a skeleton is to a human body. But without muscles, no locomotion is possible. So working with the body analogy, SDL provides the skeletal structure to build the game whereas the flesh, blood and skin are provided by 2D and 3D graphics libraries.
If this question is asked, then the most common answer one would get is that OpenGL is a graphics library in C. However, this is a misconception. In fact, OpenGL is a low-level graphics library specification. Just like J2EE, OpenGL is nothing but a set of platform neutral, language independent and vendor neutral APIs. These APIs are procedural in nature. In simple terms, this means a programmer does not describe the object and appearances; instead he/she details the steps through which an effect or an appearance can be achieved.
These steps comprise many OpenGL commands; that includes commands to draw graphic primitives such as point, line, polygon etc. in three dimensions. OpenGL also provides commands and procedures to work with lighting, textures, animations and so forth. One important aspect to keep in mind is that OpenGL is meant for rendering. Hence it does not provide any APIs for working with I/O management, window management, etc.
That's where SDL comes into the picture. To understand how OpenGL renders, it is important to understand how it interfaces between graphics application and graphics card. So here we go.
The interfacing works at three levels. They are:
While the generic implementation deals with providing a rendering layer that sits on top of the OS specific rendering system, the hardware implementation provides direct hardware interfacing and the OpenGL pipeline works at taking the command and giving it to hardware after processing. Let's look at the details.
The other phrase for generic implementation is software rendering. If the system can display generated graphics, then technically speaking a generic implementation can run anywhere. The place occupied by the generic implementation is between the program and the software rasterizer. Pictorially it would be:
It is clear from the diagram that the generic implementation takes the help of OS specific APIs to draw the generated graphics. For example on Windows it is GDI whereas on *nix systems it is XLib. The generic implementation on Windows is known as WOGL and on Linux it is MESA 3D.
Now let's move on to hardware implementation. The problem with generic implementation is that it depends on the OS for rendering; hence the rendering speed and quality differs from OS to OS. This is where hardware implementation comes in. In this case, the calls to the OpenGL APIs are passed directly to the device driver (typically the AGP card's driver). The driver directly interfaces with the graphics device instead of routing it through OS specific graphics system. Diagrammatically:
The functioning of a hardware implementation is totally different from that of a generic implementation, which is evident from the diagram. Interfacing with the device driver directly enhances both the quality and speed of the rendered graphics.
Finally, we will talk about an OpenGL pipeline. In essence, the term "pipeline" is a process that is concerned with the finer steps of a conversion or transformation. In other words, a process such as conversion can be broken down into finer steps. These steps together form the pipeline.
In a graphics pipeline, each stage or step refines the scene. In the case of OpenGL it is vertex data. Whenever an application makes an API call, it is placed at the command buffer along with commands, texture, vertex data and so forth. Upon flushing this buffer (either programmatically or by driver), the contained data is passed on to the next step where calculation-intensive lighting and transformations are applied. Once this is completed the next step creates colored images from the geometric, color and texture data. The created image is placed in the frame buffer which is the memory of the graphic device that is the screen. Pictorially this would be:
Though this a simplified version of the actual process, the above detailed process provides an insight into the working of OpenGL. This concludes this part of the discussion. However one question still remains: what are the basic steps for using OpenGL with SDL? That is what next section is about.