In my synopsis of the goals I had hoped to achieve for this workshop, I mentioned phrases like polymorphism, inheritance, encapsulation, and modularity but I didn't explain very much about them. Today I would like to focus on these key terms, discuss how they apply to us as programmers - specifically game programmers - and how this will eventually effect our design choices for this engine.

What does Object Oriented mean exactly?

When we discuss Object Oriented programming, it is important to also note the other styles of programming in order to really appreciate how this methodology helps us work on such vast projects such as games. Let me describe other styles of programming before I come back to OOP (object oriented programming).

Unstructured Programming (UP) is how most people begin learning how to program. I know it's definitely where I started! The best way to describe UP is by pointing out the very popular "Hello World" program, the humble beginnings every programmer started at =].

In a UP there is only one function ( ie. the main( ) ) and all the data in the program are exposed to this function (are global). All of the functionality of the program is implemented directly into this single main function.

Procedural Programming (PP) is the next step in the evolution of languages. It introduces the idea of encapsulating specific functionality into a separate block of code, and giving the ability of any function to call another function.

As you can see, this gives rise to the idea of reusability, or enabling a program, indeed multiple programs, the ability to reuse functions without rewriting them. The value of this is self evident. It prevents dev teams from "reinventing the wheel" so to speak, and focus on the unique aspects of their project.

The term encapsulation means that we build an entire function that performs many operations but has a predefined result. For example: I write a function for an object that draws it to the screen, and name it Render( ). Because I've encapsulated this function, other members of the dev team shouldn't need to know what happens inside this function in order to use it. At first this may seem obvious, but it becomes extremely important when you start designing your engine.

You want to make sure to build it in such a way that you can encapsulate (effectively make a black box) out of what you are coding, so other members of your team don't need to learn what you did. This allows a dev team to effectively specialize, or, gives the ability for each of us to become masters of our particular domain. In the game we develop, for example, I may be asked to encapsulate all of the graphics routine, while Churroe is asked to develop the sneak system.

As you can see both of these features are unrelated to one another, proper encapsulation would allow both Churroe and I to work on our respective parts of the engine at the same time without causing conflicts, and being wholly unaware of what the other is doing. This is good engine design, and it is also pretty much the textbook definition of modularity.

Object Oriented Programming is the next step in the progression, allowing the programmer all of the functionality of the previous programming paradigms with some new advanced features: modularity, inheritance, and polymorphism.

Lemma 3.1 - Key Concepts of OOP

While I may touch upon and relate many of the concepts of Object Oriented Programming to the task at hand, it might be good to see it in it's more pure form, one not specifically spoken in the context of video games. Also, because this workshop is designed to be a quick introduction and by no means an all expansive tutorial, I would recommend the good students to seek more information about object oriented programming and direct your browsers here

Modularity

Modularity is one of the most basic tools in any OOP programmers toolkit. The concept of modularity builds off of the programming paradigm of structured programming, where blocks of code are separated in order to both encapsulate their functionality and provide a high level of reusability. Modularity adds to this by both pairing functions with their own data set.

Example 3.1 - Modularity

Consider the following example: You have a game of pac man, and you want to have 5 ghosts on the screen. Without modularity you would be forced to keep 5 sets of data available to the various functions. You can imagine having all the images, positions of the ghosts, AI states all in one lump could get very confusing and error prone. What modularity allows you to do is encapsulate each ghost into a single module, or object:

Object Ghost
{
   int positionX, positionY;
   AISTATE ghostAI;
   IMG ghostImage;
	 
   void MoveGhost( Direction );
   void SetAI( ghostAI );
	 
}

Now we merely create 5 instances of ghost: Ghost ghost1, ghost2 ... ghost4, ghost5; Each ghost has the same types of data, but the data remains separate from each other. Notice they also get their own functions, so calling ghost1.MoveGhost(-1,10); will only move ghost1, and the other 4 ghosts will remain untouched. Also note how easy it would be to add a sixth ghost, just create a new instance of the ghost object, and viola another ghost will appear. This is obviously a very powerful technique.

Inheritance

The next step up from modularity is the concept of inheritance, or the ability to build new objects based on the properties of old objects. This technique can get rather complicated so instead of going over specific implementation I will describe the basic idea behind it, and leave it to you to research the specifics. Some key terms associated with inheritance: (if some of these terms don't make perfect sense to you from the short descriptions I recommend you do a Google search on it. Also, seeing the example that follows may make things more clear.)

• Class: this is basically an implementation of a module. It's functions and data contained in one single data type. Classes, aside from the primary building block in inheritance, also add the ability to specify whether or not a data is used only by the class, or whether it is accessible by outside functions. For more information look into public, private, and protected data members.
• Data Members: components of a class - this includes the data and functions it encapsulates.
• Base Class / Pure Virtual Class: Although these terms are not synonyms, they are related. A base class is a class that other classes derive themselves from. A pure virtual class is one that doesn't do anything in of itself, but rather, is just a template for other classes to build from. The following example might clarify this concept.
• Ancestor/Descendant: As these words imply, a descendant is a class that has inherited functionality from it's ancestor.
• Overloading: this will be covered in polymorphism, but basically it's the ability to create a function with the same name that does the same thing.
• Overriding: when you inherit from a class that has functions, you can override that behavior. So lets say I have a class Monster that can move, and it has a move command built into it. But this move command is good for zombies but not for flying creatures. When I build my Bat monster, I can override the move command that comes with monster, and modify it so it works the way I want it to for this new class Bat.

Example 3.2 - Inheritance

Consider the following example: In a video game you often have many different objects that have similar data but different implementation, or the same data but also additional functionality and data sets. Take objects for example. In any particular scene you may be presented with a number of objects like: crates on the floor, a car, an enemy, a gun on the floor.

All of these have many things in common. They all have at least position in the world, a model to represent them, and a function which draws them to the screen. What Inheritance allows us to do is make one base class, which will handle all the tasks that are the same for all the objects in the world. Then, we inherit this functionality in new classes, that expand on this ability.

class WorldObject
{
   int positionX, positionY;
   3dModel objectModel;
	 void Render( );
}

//Next lets make a specific type of object
class Crate : based on WorldObject
{
   int crateHP; //how much damage before it's destroyed?
	 int weight; //how heavy is the crate;
	 std::vector contents; //what is inside the crate?
}

An instance of Crate now will have all of the data shown above in addition to the data from WorldObject. Pretty neat huh? Since all objects will derive themselves from WorldObject, we consider this the "base class". If the WorldObject didn't implement the Render( ) function and it was expected that the inherited class "Crate" would overload it - then the WorldObject would be considered a purely virtual class, ie. a class that didn't do anything until you derived another class from it and implemented all it's functions.

Polymorphism

If you think about the word polymorphism it's meaning becomes evident: many forms. Polymorphism allows us to avoid recoding the same principal for different specifics. I won't make a big box out of this because it's really simple to understand and as this tutorial gets longer, I am getting lazier. Lets go back to our object class, and consider the following: Let's say we have our rendering function, that normally will just draw the image to the screen.

But what if we want to render it differently, say, with a custom pixel shader attached to it? Instead of writing Render( ) and RenderWithShader( shader* ) we can just write an overloaded render function, or one that takes two different types of arguments. Render( ) //no arguments, and Render( shader* ) will take a shader if we so choose. There are other uses for polymorphism, but you get the idea.

Of course there are many other features to OOP, (both good and bad!), but whole books can (and have) been written on this, so I won't dwell on it here. I encourage you guys to do some more research of your own, the internet is a veritable font of information, and I've equipped you with some of the basic terminology and concepts to help you sort through the mess =].

Until next time, have code will travel.

You can follow along their instructions 1, 2, 3 and 4, but we won't need to do step 5. Basically you need to download the platform SDK, then like after we installed DirectX go to the Options menu, and add folders to the executable, include, and library directories (corresponding to the files we just installed.) Lastly, we update a small file "corewin_express.vsprops" in our Visual Studio 8/VC/vProjectDefaults/ folder to include a few more libraries. It's pretty self explanatory, the instructions are linked above and you can contact me if you need more information.

NOTE: A lot of the functionality we'll be dealing with today you can look at as a black box, you don't need to know how it works you can just use it and focus on the rest of the engine. In fact, this source code I only wrote once, and have built every 3d engine off of it since. You should probably read it, but don't stress too much over the specifics. If you REALLY have the desire to know (I know I would, I hate people telling me not to worry about it) I recommend reading Riemer's Tutorial on this same subject. He also wrote it in C# for those of you who are just having trouble with the language barrier.

Introduction

After all the hard work getting Visual C++ and DirectX installed, it's time to actually get down to programming. In this lesson, we will be building the skeleton of our engine class and having it interface with windows for us. By the end of this lesson you will have initialized DirectX and windows, and be ready for the next lesson where we will begin rendering things to the screen. Believe it or not after this lesson everything gets a lot easier. The learning curve is sharp, and since I'm trying to quickly run through this initialization stuff I'm not taking as much time as I should explaining it. However, it's important to remind you that this workshop is about engine design, so the specific in's and outs are beyond the scope of our purpose.

Unlike the last lesson, this time I'm going to intentionally move fast and throw a lot of information at you. You are encouraged to ask questions and do individual research for the topics that you don't understand. Unlike a full fledged tutorial, these workshops are meant to expose you as quickly as possible to the subject. I will do my best to provide links to other sources for more information where I can.

I recommend you download the source code first, and have it open infront of you as you follow along. I will not be going through line by line.

Engine.h

Lets dive right in and open up "Engine.h" where the magic happens:

#pragma once

#include

#include

#include

#include

#include

#include "consts.h"

#pragma comment(lib, "d3dx9.lib")

#pragma comment(lib, "d3d9.lib")

#pragma comment(lib, "Winmm.lib")

LRESULT CALLBACK WndProc( HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam );

namespace DistortedStudios

{

class cEngine

{

public:

cEngine( );

~cEngine( );

unsigned int flags;

int Initialize( HINSTANCE hInstance, int width, int height, bool windowed);

int BeginMessageLoop( );

void Render( float timeDelta );

IDirect3DDevice9* getDevice( )
{ return pd3dDevice; }

private:

IDirect3DDevice9* pd3dDevice;

HWND winHandle;

};

}

Lemma 2.1 - Pointer Arrays are Bad

If you've cruised around any C++ forum you'll undoubtedly run into the old dinosaur of a coder who refuses to use STL containers like string and vector. Instead he'll still be using the age old technique of building pointer arrays. If you don't know what pointers are, bug Churroe about it because that's his department. But I'll give you a basic idea: You allocate sequential memory blocks and then build an array by physically manipulating the data in memory. The problem with this is, it leads to memory leaks - ie - situations where you reserve memory for your data and don't release it. It also causes a lot of problems managing the data. Now, the point of me telling you this is that you /should very rarely ever deal with pointer arrays/. STL containers are /not/ slower, in fact - in certain situations they are faster. They do not cause you to over allocate and waste memory (they manage thier own memory) and they will never cause memory leaks (unless you do something crazy with them). So no matter what people tell you: STL is your friend - use it .

The include statements are pretty self explanitory. We're going to be using windows.h header files to interface with windows, d3d9 are the primary DirectX includes, and d3dx9 are some helper functions and classes, (these will be discussed more at length in a later lesson). We are also using the STL (standard template library) classes String and Vector. While we won't actually be using either yet, it's there to remind us that, unlike regular C, we will not be using dynamically allocated char arrays for strings, nor pointer array's for data storage. If you don't know what I'm talking about, that's fine. Because it means that you can't mess it up (^_~).

There are some other lines of code in here that you may not be familiar with (or are familiar with but don't know what it means exactly, or have used but in a different way.) Like #pragma. Pragma is a precompiler directive, basically, it's a way of communicating with your compiler as it does it's thing on your code. You're able to give it certain instructions this way, to effect the final result of the code. For those of you who used an older version of C++, or have seen C++ code before you might remember those crazy #define directives. #pragma once operates the same as #ifndef FILENAME #define FILENAME #endif. It's just shorthand for "this file will only get included once." The reason this is important is that by practicing modularity we can code ourselves into trouble. This component needs to include some other file, which is including a third file, which needs to include the first file. If a file is included twice, then you get "redefinition" compile time errors. Pragma once allows us to put #include THISFILE in as many headers as we want, because the compiler will make sure to only include it once.

You'll also see the #pragma comment command. This is just me being lazy. Remember all the setting up we did before setting those include paths and library paths? Well, this is just telling the compiler to do some including without us bothering to deal with all that. Depending on how you set up, you may or may not need these. I put them in anyway, because precompiler directives are removed before you compile so they don't do any harm.

Lemma 2.2 - Namespaces

Some of you coming from C# may be familiar with namespaces, although in C++ you won't see them as often as you do in C#. The reason we use namespaces is to prevent naming conflicts throughout our code. For example, we may use another library which has a class named "cEngine". Before namespaces, programmers had adopted a simple naming convention, and we would be required to name things more descriptively, ie. cDistortedStudiosEngine. With namespaces we can write simply cEngine inside our namespace and it will protect it from being confused with anybody else. We would access it with the :: operator, ie. DistortedStudios::cEngine( ).

For more information take a look at The CPP tutorial.

Similarly I believe a few of you are coming from the land of C#. I don't know much about it, to be honest (if one of you wants to do a C# workshop I'd love to participate) but I do notice that you guys just abuse the hell out of namespace (^o^). We'll be using it a lot more sparingly, and only because this is a /design/ workshop. I generally don't even bother, but it's good programming practice to do it.

Finally we get to our engine code. More specifically our header, or class prototype. (Let's ignore that funny looking function called WinProc and the other custom include "consts.h" for now). We have a constructor and destructor (standard fare in any object oriented language). Every time an object of this class is created, the constructor is called. We use it to initialize any variables, specifically pointers (because pointers sometimes point to strange things if you don't set them to NULL right away!) Similarly the destructor is called when our class is destroyed. Back when we used pointer arrays this was where we would delete them. We still find use for them though, even though we've evolved beyond that primitive state!

The unsigned int is used for flags. What are flags? We aren't realy sure (O.o)a What I mean is, we use them whenever we need them, they are pretty all purpose, to pass data around. For example sometimes I use them in collision detection to decide which objects have been checked against who (so we don't check for the same collision twice). Or I could use it to pass information from one class to another class. How do they work? Check the lemma because while it isn't really important, I think it's cool - especially we get to use the holy grail of nerd-dom: binary operations!

Lemma 2.3 - Bitwise Badass

Generally I use the flags data member to store binary data to represent different things. It's hard to explain, but let me try and give you an example. In our everyday lives most of us generally work in a decimal system, that is deci (10) mal (meaurement). 0-9 are our digits, and each space represents the next order. so: 124, means (4 x10^0) = 4 + (2x10^1) = 20 + (1x10^2) = 100 = 124. Similarly binary is base 2, so 1010 means: (0x2^0) = 0 + (1x2^1) = 2 + (0x2^3) = 0 + (1x2^4) = 8 = 2 + 8 = 10. Now if you notice, since there are only two states any position can have (on or off, if you will) we can easily test this for flags.

Lets say 1 = FLAGA (Binary 0001), 2 = FLAGB (Binary 0010), 4 = FLAGC (Binary 0100), and 8 = FLAGD ( Binary 1000). See what's happening? The binary number 1010 means: Flag D + Flag B. We test this by using the bitwise operators OR and AND. I won't go into this now, as you'll see later how it's done (^.^).

The rest of this class is pretty easy to understand. The initialize function just sets everything up, Initializes DirectX and builds a window for us to render to. It takes a title for the window, the height and width, an HINSTANCE which will be given to us by our windows main function, and a boolean deciding whether or not we want it to be windowed or not, as parameters. Implementation of this function is probably the most difficult to swallow, and I won't really explain it a lot. Read Reimer's explanation if you really want to know.

The BeginMessageLoop function contains our main game loop. Basically, we run through a frame, check if window's has sent us any messages, decide what to do with that message, and start over again. This loop is where that funny WinProc function comes in. This function is a Windows Callback function. What that means, basically, is it's a function designed by windows, but we write the code for it. Whenever windoes sends a message to us, it sends it to be processed by our WinProc method. In the main.cpp you can see that we don't do very much with most messages: other than polling for escape to close our program - we just let window's default message handler take care of it for us.

The render function, ah! If you look at the implementation it's actually nothing at all. It just clears our screen black, starts and stops our drawing sequence, (we're not drawing anything yet but if we were it would go in there) and then presents the screen. This is actually a little important, so I won't even put it in a lemma. Any graphics API makes use of something called "back buffering" which is just a fancy way of saying "we draw on one surface while showing the user another one". This prevents the screen from flickering, which would happen if we actually watched the engine draw line by line to the screen. Instead it creates a 2d photo of the scene, puts it on a surface, and shows that to the user while it's drawing on another one. The present function, also known as "flipping" is what actually switches the two surfaces.

So now there are just two more little things to discuss before we can wrap this lesson up. I'll go with our main.cpp. As you can see, this looks a whole lot different than the plain "int main()" function we're used to using in C++. This is a special main function exposed by the windows API, and we don't have to worry too much about all the fancy stuff it gives us. As you can see from the main function itself, it's pretty bare. Guess what? It doesn't get any more complicated either. Remember once we call BeginMessageLoop( ) the engine takes over and doesn't return to this main function until the engine has shut down! So the only thing we could possibly do here is test the return values, and maybe see if the engine crashed and do some error checking. Otherwise, the rest of our code will be performed by the engine, and all her wonderful parts.

Last, but not least is that little header file called "consts". I can't claim that this is "proper" engine design since as far as I know I'm really the only person who does it. But I think it keeps my code neat and clean. I use the consts header file to hold all the (you guessed it) constant variables, debug functions, and flag properties in the game. It's important that NO CUSTOM HEADERS are included in the const file, because the const file will be used by EVERY OTHER HEADER. Even pragma once won't save us from compile errors if we cyclicly define things this way! I also use the consts header to put little helper functions that might be useful to other classes (like I have a custom int to string function, since I don't like the itoa function). Right now const only has a few return values (when we initialize instead of having it return 1; which doesnt mean much to someone else working on the code, I have it return RF_CLASS_NOT_REGISTER, which means "Return: Failed - Couldn't Register the Class". This is just for ease of debugging. Next lesson we'll be expanding this with some DEBUG macros to help us narrow down any errors we have.

Alright, you still with me? This is probably going to be the worst lesson you have to go through (worst writing most certainly) so I apologize, but you should be proud! You made it through, and we're almost at the fun and interesting stuff. Other than the math primer (that's painful to me, I don't know if you guys are good at linear algebra stuff) all that's left is just plain simple! So pat yourself on the back, have a cold beer. It gets better from here.

I'm sorry I couldn't go as in depth as you may have liked, but like I said. I really just wanted to get started on the actual purpose of this workshop. Which we may not actually start with for a little while longer, since I think the next few lessons will cover our graphics engine and the mathematics involved.

Until next time, have code will travel.

Lemma 1.1 Engine

Throughout this workshop you will be presented with various lemma's which are optional sections of reading. They are intended to give you a better understanding of the topics discussed, and deal mostly in theory and less implementation.

When I refer to the term engine it might seem confusing, as it has multiple meanings depending on context. Many think of engine's as /Graphic Engines/ such as Ogre3D or Irrlicht. However, an engine is actually the framework of code that encapsulates a particular aspect of a game. For example, we will also have /scripting engines/, /particle engines/, /sound engines/ etc.

However, "engine" might also refer to the code that connects all these specifics together into one cohesive /game engine/. The Torque Engine is a good example of a game engine, as it encapsulates graphics, physics, network, and more. This workshop deals, more precisely, in game engines. But we also touch upon graphics engines as a way to illustrate interconnectivity.

I will be writing this workshop aimed at people with a working knowledge of some programming language, but I will not assume you are familiar with C++ or DirectX. I do, however, expect anyone who is not completly comfortable with C++ to work concurrently with Churroe's C++ workshop. While specifically designed for programmers in the dev team, I hope that any member can gloss through this workshop to get a basic idea of how games in general are designed and structured for optimal performance.

What will we be doing, and what is the purpose?

Specifically, we will be constructing a very simple terrain loader, using very basic 3d techniques to implement a custom camera class and a very simple collision detection algorithm. I hope, however, that this serves a larger purpose. My goal is to really explain how we, as programmers, need to think ahead whenever implementing our own game engine. We want to take advantage of the powerful OOP (object oriented programming) aspects of C++ such as polymorphism and inheritance to create robust and expandable code. I also hope to illustrate encapsulation, reusability, modularity, and other concepts which are important to help us all work together effectively on the same project.

Some less abstract milestones in this workshop I hope to include are the following:

1. Installing and configuring Microsoft Visual C++ Express and DirectX 9.0.
2. Building an Engine class shell which we will continually expand upon throughout the workshop.
3. Interfacing with the Windows API and touch upon some windows specific topics like threading and processing.
4. Covering basic 3D math concepts such as coordinate systems, vector algebra, matrix math, quaternions, polygons, 3d spatial transformations, etc.
5. Getting a grasp of basic DirectX systems and operation through vertex buffers, index buffers, meshes, etc.
6. Learning basic 3D graphics techniques like culling, projection, etc.

I'll do my best to keep the pace depending on your feedback, so it's not too slow and boring. (^_^);

Alright! I'm pumped, when do we start?

Right now! Lets dew eet. The first thing we want to do is get you all setup in our IDE (Integrated Development Environment), which means you're going to have to do some downloading. If you're on a 56k modem you can start downloading and I'll let you know when you can get up to make a sandwich ( or get in touch with your local broadband provider as 56k went extinct around the time of the wooly mammoth ).

First we'll be grabbing our IDE Visual C++ Express edition from Microsoft. I chose this for a few reasons. Firstly, it's free. Secondly, since I use Visual Studio this lets me easily port over a lot of code. Don't worry though, as throughout this workshop I'll be using the Express edition with you guys (so you don't get weird compile errors or something). Thirdly, it'll be good to have everyone on the same compiler that way we avoid nasty hiccups like #2. And lastly, I'm comfortable with it. And since I am going to have to answer any questions, it'll help.

So mosey on over to Microsoft's Visual C++ Express web page And click on the button in the upper right that says "Download". Scroll down to the Visual C++ part and click ok. It'll download quick. Start the setup. When you come to the screen asking if you want the MSDN I would recommend it (even though it's like 300mb). It's basically the documentation for the language. There is an online format so you don't /have/ to download it. And if you're short on HD space you can feel safe to skip it. Alone the IDE is about 70mb. Once you see it start downloading / installing you can move on to the next step.

While this is going lets grab the DirectX SDK (Software Developer's Kit). This is a little larger, (okay more like eight times larger) and is set at a whopping 441mb. So get that going. Now you can go make a sandwich. While you do that, I'm going to clear some room on my hard drive (~.~);;.

Lemma 1.2 - Why is it so damn HUGE?

Mm pastrami. Okay, so you're at the Setup complete screen on Visual C++, lets go ahead and register that now. I already have a Windows ID thingy-job because I have an MSN account. Fill out the little survey and then check your email. Click the link and you now have your Registration key.

Go ahead and launch the Visual C++ program. Click Help | Register Product, drop your key in, and done. You're officially ready to start running some C++ codes (>^o^)9 But, lets get DirectX up and running first. This actually is a little bit more complicated, so stay with me.

Track down and run the dx file you downloaded (should be something like dxsdk_apr2007.exe). Run it and wait for it to extract, then continue with the install. I will be installing to the default directory of C:Program FilesMicrosoft DirectX SDK (April 2007) It's important you make a note of where you install these files as we will need this location to setup MSVC (Microsoft Visual C).

So lets launch Visual C++, it'll take a few moments to initialize and you'll be presented with a start page. I usually disable this because it just makes it load slower and I don't really care about whats new. Anyway, What we want to do right now is tell MSVC where our DirectX files are located, so that when we compile our programs it knows where to look for the required files. So follow along with this fancy image I cooked up:

Click to Enlarge

1. Tools | Options
2. Projects and Solutions | VC++ Directories
3. Show Directories For (Drop Down box) and select "Include Files"

Click to Enlarget

1. Click the manilla folder.
2. On the new edit line that appears click on the ellipsies (that "...").
3. In the dialog that appears navigate to where you installed DirectX 9.
4. Then click on the include file inside there. My include files are located here: C:Program FilesMicrosoft DirectX SDK (April 2007)Include
5. Click the open button. The Options dialog should now have the path to the include files in it.
6. Go back to the "Show Directories For" menu, and select "Library Files".
7. Click the ellipsies again, navigate to your DirectX folder, click on the lib folder
8. Depending on your processor select x86 or x64. I have an x86 so my libraries are located here: C:Program FilesMicrosoft DirectX SDK (April 2007)Libx86

Lemma 1.3 - x64, x86, what now?

If you're not sure which library to select, there is a quick way to find out. In your start menu select run, and in the prompt type cmd. At the command prompt type the following: "set PROCESSOR_ARCHITECTURE" (without the quiotes). If the program returns "PROCESSOR_ARCHITECTURE=x86" use the x86. If it says "PROCESSOR_ARCHITECTURE=AMD64" use x64. Double check if you're not exactly sure, I'm using an AMD Athalon64, but I still have x86 architecture.

If you want more information on what all this means I recommend reading Wiki's article on the subject.

You /should/ be all ready to start running DirectX programs in C++! Lets do a little test. Go to File | New... | Project. Then Under "Visual C++" select General (at the bottom of the list), then Empty Project. Type in a name for your project and a default directory. Then click ok. On the left of the screen is a solution explorer, with 3 folders in it: Header Files, Resource Files, and Source Files. Right click Source Files Then select Add | New Item... . Select Code | C++ File (.cpp). Name it main.cpp. You'll be presented with a blank space. Type the following:

#include "d3dx9.h"

#pragma comment(lib, "d3dx9.lib")

int main( )

{

system("PAUSE");

return 0;

}

Press F5. You'll get a warning about not setting your debugger, continue debugging anyway. If it compiles and you get a console that says "Press any key to continue..." *Congrats!* You're officially ready to start making some shiny graphics.

It's going to be a little bit while I get things organized for the next few lessons. Hopefully, Churroe will keep you busy while I figure how I want to go about talking about this. Till next time, have code will travel.