Windows Programming Essentials


Windows Programming Essentials

Before you can even think about developing games for Windows, you need to have some knowledge about what it takes to develop a basic Windows program. Windows programming is unlike other kinds of traditional programming, as you'll soon find out. Windows programming begins and ends with the Win32 API (Application Programming Interface) , which is the set of data types and functions that are used to create Windows programs. The Win32 API is quite massive, and requires a significant learning curve to get comfortable with its many facets. Fortunately, you only need to use a relatively small portion of the Win32 API to create Windows games.

graphics/book.gif

The Win32 API is built into all compilers that support Windows programming, such as Microsoft Visual C++. By the way, the "32" in Win32 has to do with the fact that the API is a 32-bit API. This is significant because the original Windows API was developed for 16-bit programming. Remember Windows 3.1?


Certain aspects of Win32 programming are common to all Windows programs, regardless of whether you're creating a game or a word processor. These common Windows program features are primarily what you learn about in this lesson. This will provide you with a solid foundation on which to build game specific knowledge and code. If you're getting antsy, just hang in there through this lesson, and I promise you'll get to create some interesting programs soon enough.

graphics/book.gif

In the previous lesson, you learned how object-oriented programming is important for game development. You might be curious as to how OOP impacts Windows programming with Win32. Win32 is a procedural API that relies on object-oriented constructs to represent Window elements such as windows and icons. An example of this is the window object, which represents a rectangular area on the screen. Window objects have data associated with them along with Win32 API functions that are used to manipulate them.

You can think of Win32 programming as a hybrid type of object-oriented programming.


Event-Driven Programming

The most dramatic switch for most people new to Windows programming is the fact that Windows programs are event-driven . This is a fancy way of saying that Windows programs respond to their environment, as opposed to the environment taking cues from the program. In the world of events, the flow of your program follows events external to the program such as mouse clicks and key presses. Instead of writing code to scan for a key press, you write code to take some action whenever a key press is delivered to the program. As you get more comfortable with the concept of events, you'll see how just about any change in the environment can trigger an event. You can design your programs to ignore or respond to any events you choose.

The event-driven nature of Windows has a lot to do with the fact that it is a graphical operating system. When you think about it, Windows faces a seriously challenging problem in allowing multiple programs to run at the same time and share screen space, memory, input devices, and virtually every other system resource. The event-driven approach to handling user interactions and system changes is extremely important in making Windows as flexible and powerful as it is. In terms of games, events make it possible to divide tasks according to what has taken place. In other words, a left mouse click, a right mouse click, and a key press on the keyboard are handled as separate events.

Communicating with Messages

In traditional non-graphical programs, a program calls a system function to accomplish a given task. Graphical Windows programs introduce a twist on this scenario by allowing Windows to call a program function. When I say "Windows calls a program function," I mean that Windows sends the program a message , which is a notification containing information about an event. Windows sends messages whenever something takes place that a program might want to know about and respond to, such as the user dragging the mouse or resizing the main program window.

graphics/book.gif

Windows programs are also commonly referred to as Windows applications. So, you'll often see me using the terms program and application interchangeably ”just know that they mean the same thing.


Messages are always sent to a specific window, usually the main program window; every Windows program has a main window. Many windows are floating around in a typical Windows session, and all of them are receiving messages at one time or another that inform them of changes going on around them. Each of these windows has a window procedure , which is a special function that processes messages for the window. Windows handles the details of routing messages to the appropriate window procedures; your job is to write code in the window procedure for your program that responds to certain messages.

With the probability of many different messages being sent to a window, you might wonder how many of them you need to worry about in a game. And what happens to the messages you ignore? In the average Windows program, including most games, you usually only concern yourself with a handful of messages. You write code to respond to these messages, and you allow a default Windows message handler to take care of messages you ignore; Windows provides default handlers for all messages. By the way, a handler is simply a chunk of code that is called in response to a message; its job is to "handle" the event.

Understanding Device Independence

In the golden era of DOS games, it was common for game developers to program games so that they worked directly with the memory on your graphics card. The benefit to this was that it made games extremely fast because the graphics for a game was being processed directly by the graphics card. Although this worked great for DOS games, you don't have quite the same luxury in Windows. Generally speaking, Windows is specifically designed to keep you from interacting directly with hardware such as graphics cards. This design is known as device independence , which simply means that Windows programs draw graphics in a manner that is independent of the specific hardware devices that get drawn on. The upside to this approach is that Windows programs work on a wide range of hardware without any special modification. This was impossible in the DOS world.

Device independence in Windows is made possible by the Graphical Device Interface , or GDI , which is the part of the Win32 API that deals with graphics. The GDI sits between a program and the physical graphics hardware. Under the GDI, graphics are drawn to a virtual output device; it is up to Windows to resolve the virtual device down to a specific hardware device via the system configuration, hardware drivers, and so on. Even though the GDI is designed to keep you at an arm's length from graphics hardware, it is still quite powerful. In fact, all the games developed throughout this book are based solely on the GDI.

Storing Program Information as Resources

Just about every Windows program relies to some extent on resources , which are pieces of information related to a program outside of the program code itself. For example, icons are a good example of resources, as are images, sounds, and even menus . You specify all the resources for a Windows program in a special resource script, which is also known as an RC file. The resource script is a text file containing a list of resources that is compiled and linked into the final executable program. Most resources are created and edited with visual resource tools, such as the icon editor integrated into the Visual C++ development environment.

Dealing with Strange Data Types

Perhaps the toughest part of Windows programming is getting comfortable with the strange data types that are a part of every Windows program. One of the most common data types you'll see is called a handle, and it's nothing like a door handle in the real world. A handle in Windows is a number that refers to a graphical Windows object such as a window or icon. Handles are important because an object is often moved around in memory by Windows, which means that its memory address is a moving target. A handle gives you a fixed reference to an object independent of the object's physical location in memory. Handles are used throughout the Win32 API when dealing with Windows objects. Don't worry if handles sound a little complicated right now because they'll start making more sense as you see them used in a real Windows program.

In addition to handles, the Win32 API introduces a variety of new and different data types that you might find strange at first. All Win32 data types appear in uppercase, so they are easily identifiable. For example, a fairly simple and commonly used Win32 data type is RECT , which represents a rectangle structure. There is also an HWND data type, which represents a handle to a window. Win32 is chock full of data types, so it's futile to try and cover them all in one place. Instead, you'll learn about new data types as you encounter them throughout the book.

In order for your Windows programs to be able to recognize and use Win32 data types, you must import them into your program's source files. This is accomplished with a single line of code:

 #include <windows.h> 

The header file windows.h defines the entire Win32 API, and is essential in every Win32 application. It's generally a good idea to import it first in every relevant source file.

Unconventional Coding Conventions

If you've ever seen the code for a Windows program before, you might have wondered what was going on with the weird variable names . Programmers have long struggled with the problem of writing code that is easy to understand. Windows makes this problem worse by introducing a lot of different data types, which makes it difficult to keep up with which variables are of which type. Legendary Microsoft programmer Charles Simonyi came up with a pretty crafty solution to this problem that is now known as Hungarian notation. (Mr. Simonyi is Hungarian.) With Hungarian notation, variable names begin with a lowercase letter or letters that indicate the data type of the variable. For example, integer variable names begin with the letter i . Following are some Hungarian notation prefixes commonly used in Windows programming:

  • i ” integer

  • b ” Boolean ( BOOL )

  • sz ” string terminated by zero

  • p ” pointer

  • h ” handle

  • w ” unsigned short integer ( WORD )

  • dw ” unsigned long integer ( DWORD )

  • l ” long integer

graphics/book.gif

BOOL , WORD , and DWORD are commonly used Win32 data types.


Applying Hungarian notation is very simple. For example, an integer count might be named iCount , whereas a handle to an icon might be named hIcon . Similarly, a null-terminated string storing the name of a sports team might be named szTeamName . Keep in mind that Hungarian notation is completely optional, but it really is a good idea. You'll encounter Hungarian notation in all the code in this book, and after a while you'll hopefully begin to appreciate the convenience it offers.



Sams Teach Yourself Game Programming in 24 Hours
Sams Teach Yourself Game Programming in 24 Hours
ISBN: 067232461X
EAN: 2147483647
Year: 2002
Pages: 271

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net