Contents  Introduction  Direct Input's  A Breeze  Timing and  Windoze  The Menu System  Putting the  Pieces Together  Until Next Time  Printable version     The Series  Part 1  Part 2  Part 3  Part 4  Part 5  Part 6

Direct Input's A Breeze

Are you ready? Good. For all intents and purposes, Direct Input code has the same basic format as our Direct Draw code. You will notice the more you use DirectX that it is all the same ... just different parameters. Anyway, we will want to put together an initialization and a shutdown routine. We are also going to look at the coding of a routine to handle reading the keyboard. The accompanying code has routines for the mouse in it also. But, since we don't care about the mouse in our game, I won't be covering it in the article. It is there however ... so feel free to use it if you would like.

To start with ... I guess you are going to want to see the Direct Input initialization routine.

This code isn't very complex at all. It starts by creating the main Direct Input object. This is the object that you use to derive all of the device objects and such. Just a single call -- passing it the address of the variable, the version of Direct Input to use, and the instance of our application. Then, we call routines to setup our keyboard and mouse. Thus, we need to take a peek at the routine that initializes the keyboard.

The first thing that this code does, is attempt to create the keyboard device. Remember, like the Direct Draw object, the Direct Input object is generic and other things must be created off of it ... such as keyboard devices. Once you have created the object you will need to set the cooperative level on it. In our case we would like to have exclusive use of it.

Now that we have the keyboard's cooperative level set, we can inform Direct Input of the type of data that it will receive. For the keyboard, this is c_dfDIKeyboard. The final step left in initializing our keyboard is acquiring it. This is the step that most people tend to forget. Currently, we have an object that we have told to accept keyboard data and take exclusive access of the keyboard. But, we have not told it that it has permission to take control of the object. So, we make a call and that's that.

We are now ready to use it. That means we need to have a look at the code to read the keyboard. Unless, of course, you would prefer to simply make a call, and never see the code in your life. Oh my!! What kind of programmer are you? I can't believe you just thought that! Here's the code anyway ...

This code first tests to see if we have a valid object. If not, it could be for a number of reasons ... such as the keyboard not being plugged in, or maybe a bad port. This is unlikely to happen, but better safe than sorry.

Then, if we exist, the code reads the device. In the case of the keyboard, all entries are cleared and are only set if the key has been actively pressed down at the time of the read. If so, then the keyboard constant associated with that key is set to TRUE, otherwise it is left as FALSE. They key constants are defined in the "DInput.inc" file --- examples are: DIK_J, DIK_N, etc.

Finally the only thing left to do is shutdown the Direct Input stuff. That is done with the following routine.

This code un-acquires the devices that we acquired during initialization and then releases them. Then, it releases the main Direct Input object that we created. That is all that needs to be done during the shutdown process.

Direct Input is one of the easiest portions of DirectX to write code in. There are very few calls that you need to make, and most of them are really straight forward, with the exception of that "acquire" thing. The advantage is that we now have a high performance input system to use and do not have to rely on Windows messages to bring us our needed information.

With Direct Input completely out of the way we have what we need to code our menu system. But before we get to that, let's make a brief sojourn to the land of timing, and see what kind of havoc we can INVOKE.

Next : Timing and Windoze