Tricks of the Windows Game Programming Gurus:The Windows Programming Model

All ITKnowledge Source Code Search Tips Advanced Search |

| Tricks of the Windows Game Programming Gurus by Andre LaMothe Sams, Macmillan Computer Publishing ISBN: 0672313618 Pub Date: 09/27/99

Search this book:

Previous | Table of Contents | Next

You might be wondering if you have any control over the creation of threads. The answer is yes!!! In fact, this is one of the most exciting things about Windows game programming—we can create as many threads as we want to perform other tasks in addition to our main game process.

> Note: In Windows 98/NT, there is actually a new type of execution object called a fiber, which is even simpler than a thread. (Get it? Threads are made of fibers.)

This is much different than how a DOS game is written. DOS is a single-threaded OS, meaning that once your program runs, it’s the only thing running (except for an interrupt handler from time to time). Therefore, if you want any kind of multitasking or multithreading, you must simulate it yourself (check out Sams Teach Yourself Game Programming in 21 Days for a complete DOS-based multitasking kernel). And this is exactly what game programmers have been doing over the years. Granted, simulating multitasking and multithreading is nowhere near as robust as having a complete OS that supports them, but for a single game, it works well enough.

Before we move into real Windows programming and the code that makes things happen, there is one detail that I want to mention. You might be thinking that Windows is a magical OS because it allows multiple tasks or programs to run at once. Remember, this is not true. If there is a single processor, only one execution stream, thread, program, or whatever you want to call it can run at a time. Windows just switches between them so quickly that it seems as if more than one program is running. On the other hand, if you have more than one processor, multiple programs can run. For example, I have a dual Pentium II computer, with two 400MHz Pentium II processors running Windows NT 5.0. With this configuration, two instruction streams can be executed at the same time.

In the near future, I would expect that new microprocessor architectures for personal computers will allow multiple threads or fibers to be executed as part of the processors’ design. For example, the Pentium has two execution units—the U pipe and V pipe. Hence, it can execute two instructions at once. However, these two instructions are always from the same thread. Similarly, the Pentium II can execute up to five simple instructions at once, but again from the same thread.

#### The Event Model

Windows is a multitasking/multithreaded OS, but it’s also an event-driven OS. Unlike DOS programs, most Windows programs sit and wait for the user to do something, which fires an event, and then Windows responds to the event and takes action. Take a look at Figure 2.4 to see this graphically. It depicts a number of application windows, each sending their events or messages to Windows to be processed. Windows does some of the processing, but most of the messages or events are passed through to your application program for processing.

Figure 2.4 Windows event handling.

The good news is that you don’t need to concern yourself with the other applications that are running. Windows will handle them for you. All you have to worry about is your own application and the processing of messages for your window(s). This wasn’t the entire truth in Windows 3.0/3.1. Those versions of Windows weren’t true multitasking operating systems, and each application had to yield to the next. This meant that applications running under these versions had a rather rough or sluggish feel. If other applications were hogging the system, there wasn’t anything that the compliant applications could do. However, this isn’t the case with Windows 9X/NT. The OS will pull the rug out from under your application whenever it feels like it—of course, it pulls it so quickly that you’ll never notice!

At this point, you know all you need to know about OS concepts. Luckily, Windows is such a nice OS to write games for these days that you won’t have to worry about scheduling—all you need to worry about is the game code and pushing the machine to its limits.

Later in this chapter, we’ll get into some actual programming so you can see just how easy Windows programming is. But (there’s always a but) before we do that, we need to cover some conventions that Microsoft programmers like to use. This way, you won’t be bewildered by all the weird function and variable naming.

### Programming the Microsoft Way: Hungarian Notation

If you’re running a company like Microsoft, with thousands of programmers working on various projects, at some point you have to come up with a standard way of writing code. Otherwise, chaos ensues. Therefore, a man named Charles Simonyi was put in charge of creating a specification for writing Microsoft code. This spec has been used ever since as a basic guideline for writing code. All Microsoft APIs, interfaces, technical articles, and so on use these conventions.

The specification is generally referred to as Hungarian notation, probably because creating it and working those late hours made him hungry. Or maybe it was because he was from Hungary. We’ll never know. The point is, you have to learn it so you can read Microsoft code.

Hungarian notation consists of a number of conventions relating to naming:

  • Variables
  • Functions
  • Types and constants
  • Classes
  • Parameters

Previous | Table of Contents | Next

Copyright © Macmillan Computer Publishing, Inc.

Products | Contact Us | About Us | Privacy | Ad Info | Home
Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.