What you’ll learn in this chapter:
OpenGL is purely a graphics API, with user interaction and the screen/window handled by the host environment. To facilitate this partnership, each environment usually has some extensions that “glue” OpenGL to its own window management and user interface functions. This glue is code that associates OpenGL drawing commands to a particular window. It is also necessary to provide functions for setting buffer modes, color depths, and other drawing characteristics.
For Microsoft Windows, the glue code is embodied in six new wiggle functions added to OpenGL (called wiggle because they are prefixed with wgl rather than gl), and five new Win32 functions added to the Windows NT and 95 GDI. These gluing functions are explained in this chapter, where we will dispense with using the AUX library for our OpenGL framework.
In Chapter 3 we used the AUX library as a learning tool to introduce the fundamentals of OpenGL programming in C. You have learned how to draw some 2D and 3D objects and how to specify a coordinate system and viewing perspective, without having to consider Windows programming details. Now it is time to break from our “Windowless” examination of OpenGL and see how it works in the Windows environment. Unless you are content with a single window, no menus, no printing ability, no dialogs, and few of the other features of a modern user interface, you need to learn how to use OpenGL in your Win32 applications.
Starting with this chapter, we will build full-fledged Windows applications that can take advantage of all the operating system’s features. You will see what characteristics a Windows window must have in order to support OpenGL graphics. You will learn which messages a well-behaved OpenGL window should handle, and how. The concepts of this chapter are introduced gradually, as we use C to build a model OpenGL program that will provide the initial framework for all future examples.
Thus far in this book, you’ve needed no prior knowledge of 3D graphics and only a rudimentary knowledge of C programming. From this point on, however, we assume you have at least an entry-level knowledge of Windows programming. (Otherwise, we’d have wound up writing a book twice the size of this one, and we’d have had to spend more time on the details of Windows programming and less on OpenGL programming.) If you are new to Windows, or if you cut your teeth on one of the Application Frameworks and aren’t all that familiar with Windows procedures, message routing, and so forth, you’ll want to check out some of the recommended reading in Appendix B, Further Reading, before going too much further in this text.
With the AUX library we had only one window, and OpenGL always knew that we wanted to draw in that window (where else would we go?). Your own Windows applications, however, will often have more than one window. In fact, dialog boxes, controls, and even menus are actually windows at a fundamental level; it’s nearly impossible to have a useful program that contains only one window. So how does OpenGL know where to draw when you execute your rendering code? Before we try to answer this question, let’s first review how we normally draw in a window without using OpenGL.