Although the assignments are about graphics programming that is not dependent on any particular API like OpenGL or DirectX, some means is necessary for your C++ program to send output to workstation graphics hardware. OpenGL was chosen for this purpose because it is a widely accepted standard that is supported on virtually all hardware and operating systems.
The OpenGL Programming Guide, commonly referred to as "The Redbook". Not specifically required for completion of the homework assignments, but everyone who programs graphics owns a copy. An alternative to purchasing the latest version paper Redbook is the online older versions listed at the bottom of the book's web page.
The OpenGL Utility Toolkit (GLUT) handles most of the system dependent actions required to display a window, put OpenGL graphics in it, and accept mouse and keyboard input. It is used to create the skeleton for all the assignments that hides Windows programming issues from you so you can concentrate on programming graphics.
OpenGL is part of Windows XP and the Visual Studio. Its header files are usually in C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl, so they can be included with the statements:#include <GL/gl.h>
The GLU (GL Utilities) in glu.h refers to a set of utility functions that make some OpenGL operations easier to program. It is standard on all OpenGL implementations and is generally thought of as part of standard OpenGL.
Tip: Both gl.h and glu.h are included in GLUT, so if glut.h is included in your source file, gl.h and glu.h don't need to be explicitly included.
OpenGL is part of Windows XP and the Visual Studio. Its library files are usually in C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Lib:
They must be included as additional dependencies in a project that uses them To do this, right click on the project name in the Solution Explorer tab and select Properties -> Linker -> Input -> Additional Dependencies and enter the library file names separated by spaces. The symptom of not doing this is unresolved external errors referring to OpenGL functions.
Programming with OpenGL may seem a little different from what you are accustomed to. Below are the paradigms that are most characteristic.
An OpenGL implementation is often described as a state machine. That is, it has an inherent state represented by numerous internal variables, all of which remain in their default state until changed via an OpenGL call, and remain in that new state until changed again via an OpenGL call. OpenGL will not display graphics properly, or at all, if it is not in the appropriate state, and many OpenGL programming errors are due to the programmer misunderstanding or making incorrect assumptions about the OpenGL state at some point.
The reason OpenGL operates like a state machine is to avoid having to pass many arguments on each function call.
Communication between an application program and OpenGL must eventually pass through the workstation data bus to the graphics hardware. The data bus is typically much slower than the workstation CPU and graphics hardware and so can often be the bottleneck in high speed graphics. To maintain the highest possible speed, OpenGL passes as few arguments as possible in its function calls, as can be seen by reviewing the OpenGL documentation. All calls assume many internal variables have been previously set to the values you want.
OpenGL function and data names, and their documentation, assume an understanding of common and advanced graphics terminologies. For example, the help for the glFrustum() function states that "The glFrustum function multiplies the current matrix by a perspective matrix." This won't be of much help unless you know what a frustum and a perspective matrix is. By the end of the course, most of the graphics terminology will be very familiar, but initially you should be able to get by without too much detailed knowledge.