In this chapter we will look at obtaining input using various Win32 functions such as GetAsyncKeyState, DirectInput, and XInput. DirectInput allows your game to support a myriad of input devices without forcing you to know the exact details of each device. A small sample of the devices supported by DirectInput is shown here.

DirectInput was last updated in DirectX 8 and is generally considered deprecated. But Microsoft’s new API XInput only supports Xbox 360 controllers, which means that XInput does not support keyboards and mice devices. We can still use DirectInput for keyboards and mice, but we could easily obtain the states of these devices using various Win32 functions, which we’ll see throughout this chapter. For game pads and other next-generation controllers for the Windows OS it is recommended to use XInput.

Unfortunately this alienates non-Xbox 360 controllers, and if the need to support these devices exists, developers can still fall back to DirectInput since there are no Win32 functions for game controllers in the same way there are for mice and keyboards. Because a need to support these devices still exists, and since XInput does not support them, DirectInput is still a viable solution that is worth learning.

XInput is a relatively new API that first hit the scene in the later versions of DirectX 9 and is available for detecting input from Xbox 360 game controllers. Game controllers include not only the standard Xbox 360 game pad but also these various devices:

In this chapter we will look at detecting keyboard and mouse input by obtaining the device states using Win32 functions as well as through DirectInput. We’ll also look at how to detect input from Xbox 360 controllers through XInput.

Win32 applications that we’ve been developing throughout this book have generally used the following windows procedure callback function for events:

LRESULT CALLBACK WndProc( HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam )
{
    PAINTSTRUCT paintStruct;
    HDC hDC;

    switch( message )
    {
        case WM_PAINT:
            hDC = BeginPaint( hwnd, &paintStruct );
            EndPaint( hwnd, &paintStruct );
            break;

        case WM_DESTROY:
            PostQuitMessage( 0 );
            break;

        default:
            return DefWindowProc( hwnd, message, wParam, lParam );
    }

    return 0;
}

There are a ton of events that we could support, one of which is the WM_KEY DOWN and WM_KEYUP events for keyboard actions. As an example, responding to the Escape key being pressed, and exiting the application as a result, would look like this:

LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    PAINTSTRUCT paintStruct;
    HDC hDC;

    switch( message )
    {
        case WM_PAINT:
            hDC = BeginPaint( hwnd, &paintStruct );
            EndPaint( hwnd, &paintStruct );
            break;

        case WM_DESTROY:
            PostQuitMessage( 0 );
            break;

        case WM_KEYDOWN:
            switch(wParam)
            {
                case VK_ESCAPE:
                   PostQuitMessage(0);
                   break;
            }
            break;


        default:
            return DefWindowProc( hwnd, message, wParam, lParam );
    }

    return 0;
}

The main problem with the message queue is that this method is far too slow. This method relies on the operating system sending the message to the application that a key was pressed. This is not instant, and there is often a delay between messages. For video games it is highly recommended that you avoid the message queue.

A better option is to obtain the state of the device the moment we want it (e.g., every frame). This can easily be done in our demos by adding the following code to the Update function:

void KeyboardDemo::Update( float dt )
{
    if( GetAsyncKeyState( VK_ESCAPE ) )
    {
        PostQuitMessage( 0 );
    }
}

We can use GetAsyncKeyState to essentially tell us if a button is being pressed. The only parameter to this function is the virtual key code for the keyboard button we want to test for, and this provides an easy method to detect keyboard input. There is also the option to use the Win32 functions GetKeyState and GetKeyboardState, whose prototypes can be seen as follows:

SHORT WINAPI GetKeyState( int nVirtKey );

BOOL WINAPI GetKeyboardState( PBYTE lpKeyState );

DirectInput is initialized in a very similar manner to other DirectX components, requiring the creation of both a DirectInput object as well as an input device.

The DirectInput object provides the interface needed to access DirectInput devices. Through this interface, you are able to create an instance of a device, enumerate the devices on a system, or check the status of a particular device.

Once you have the DirectInput object created, you have to create the device. The DirectInput device that you create will enable you to gain specific access to an input device, be it a keyboard, joystick, or other gaming device.

After creating the device, you need to gain access to its input. This is done through a process called acquiring a device. When you acquire a device, you are provided with access to initialize the device, get a list of its capabilities, or read its input.

It may seem like a lot of trouble to go through just to get a couple of keystrokes from a keyboard or game pad, but having direct access to your input device will make your life simpler later on.

Now that you have access to the device, you’re able to read input from it each frame. For example, if you are using a game pad as your input device, you can check to see if the user has pressed the direction buttons or if one of the predefined action buttons has been pressed. If so, you can then act on this information.

At this point, you should have a clear understanding of the process needed to get DirectInput up and running and getting data from an input device. We’ll now walk you through the code needed to do just that.

HRESULT WINAPI DirectInput8Create(
HINSTANCE hinst,
DWORD dwVersion,
REFIID riidltf,
LPVOID *ppvOut,
LPUNKNOWN punkOuter );

LPDIRECTINPUT8 directInputObject;

HRESULT hr = DirectInput8Create( hInst, DIRECTINPUT_VERSION,
    IID_IDirectInput8, ( void** )&directInputObject, 0 );

if FAILED( hr )
{
    return false;
}

HRESULT CreateDevice( REFGUID rguid, LPDIRECTINPUTDEVICE *lplpDirectInputDe
vice, LPUNKNOWN pUnkOuter );

LPDIRECTINPUTDEVICE8 keyboardDevice;

HRESULT hr = directInputObject ->CreateDevice( GUID_SysKeyboard,
    &keyboardDevice, 0 );

if FAILED(hr)
{
    return false;
}

typedef struct DIDATAFORMAT
{
    DWORD dwSize;
    DWORD dwObjSize;
    DWORD dwFlags;
    DWORD dwDataSize;
    DWORD dwNumObjs;
    LPDIOBJECTDATAFORMAT rgodf;
} DIDATAFORMAT, *LPDIDATAFORMAT;

HRESULT hr = keyboardDevice ->SetDataFormat( &c_dfDIKeyboard );

if FAILED(hr)
{
    return false;
}

hr = keyboardDevice->SetCooperativeLevel( hwnd,
    DISCL_FOREGROUND | DISCL_NONEXCLUSIVE );

if FAILED(hr)
{
    return false;
}

HRESULT hr = keyboardDevice->Acquire( );

If( FAILED( hr ) )
{
    return false;
}

HRESULT EnumDevices( DWORD dwDevType, LPDIENUMDEVICESCALLBACK lpCallback,
    LPVOID pvRef, DWORD dwFlags );

HRESULT hr;

hr = directInputObject->EnumDevices( DI8DEVCLASS_GAMECTRL,
     EnumDevicesCallback, NULL, DIEDFL_ATTACHEDONLY ) ;

If( FAILED( hr ) )
    return false;

BOOL CALLBACKDIEnumDevicesCallback( LPCDIDEVICEINSTANCElpddi, LPVOID pvRef );

typedef struct DIDEVICEINSTANCE {
    DWORD dwSize;
    GUID guidInstance;
    GUID guidProduct;
    DWORD dwDevType;
    TCHAR tszInstanceName[MAX_PATH];
    TCHAR tszProductName[MAX_PATH];
    GUID guidFFDriver;
    WORD wUsagePage;
    WORD wUsage;
} DIDEVICEINSTANCE, *LPDIDEVICEINSTANCE;

BOOL CALLBACK EnumDevicesCallback ( const DIDEVICEINSTANCE* pdidInstance,
    VOID* pContext )
{
    HRESULT hr;

    hr = directInputObject ->CreateDevice( pdidInstance->guidInstance,
         &keyboardDevice, 0 );

    if( FAILED( hr ) )
    {
        return DIENUM_CONTINUE;
    }

    return DIENUM_STOP;
}

HRESULT EnumObjects( LPDIENUMDEVICEOBJECTSCALLBACK lpCallback,
    LPVOID pvRef, DWORD dwFlags );

BOOL CALLBACK DIEnumDeviceObjectsCallback (
    LPCDIDEVICEOBJECTINSTANCE lpddoi, LPVOID pvRef );

while( 1 )
{
    HRESULT hr = keyboardDevice->GetDeviceState( sizeof( buffer ),
        ( LPVOID )&buffer );

    if( FAILED( hr ) )
    {
        hr = keyboardDevice->Acquire( );

        while( hr == DIERR_INPUTLOST )
        {
            hr = mouseDevice->Acquire( );
        }
}

if( directInputObject )
{
    if( keyboardDevice )
    {
        keyboardDevice->Unacquire( );
        keyboardDevice->Release( );
        keyboardDevice = 0;
    }

    directInputObject->Release( );
    directInputObject = 0;
}

Getting input from the keyboard is rather simple because it is a default device. The keyboard requires a buffer consisting of a 256-element character array.

The character array holds the state of each key on the keyboard. The state of one or multiple keys can be held in this array each time the keyboard device is read from. Most games will require that the input device be read from each frame from within the main game loop.

Before you can read from the keyboard though, you need an easy way of determining which key on the keyboard was pressed. The macro KEYDOWN, provided next, simply returns TRUE or FALSE based on whether the key you are checking for is pressed.

#define KEYDOWN( name, key ) ( name[key] & 0x80 )

An example of reading from the keyboard is found here:

#define KEYDOWN( name, key ) ( name[key] & 0x80 )

char buffer[256];

while ( 1 )
{
    keyboardDevice->GetDeviceState( sizeof( buffer ), ( LPVOID )&buffer );

    if( KEYDOWN( buffer, DIK_LEFT ) )
    {
        // Do something with the left arrow
    }

    if( KEYDOWN( buffer, DIK_UP ) )
    {
        // Do something with the up arrow
    }
}

As you can see, the main game loop calls GetDeviceState each frame and places the current state of the keyboard into the input buffer. The KEYDOWN macro is then used to check for the state of certain keys.

On the companion website in the Chapter5/Keyboard folder is a demo application that demonstrates keyboard input using DirectInput and GetA syncKeyState. The GetAsyncKeyState function is used to test whether the Escape key was pressed, which will cause the demo to quit. This is done for demonstration purposes and did not require its own demo for such a simple line of code.

The Keyboard demo builds off of the Triangle demo from Chapter 2. In this demo we will change the color of the triangle being displayed as the user presses the up and down arrow keys. To accomplish this we will have a variable that keeps track of the currently selected color, and we’ll cycle through the colors using this value. The KeyboardDemo.h header file can be seen in Listing 5.1.

#include"Dx11DemoBase.h"

class KeyboardDemo : public Dx11DemoBase
{
    public:
        KeyboardDemo( );
        virtual ~KeyboardDemo( );

        bool LoadContent( );
        void UnloadContent( );
        void Update( float dt );
        void Render( );
    private:
        ID3D11VertexShader* customColorVS_;
        ID3D11PixelShader* customColorPS_;
        ID3D11InputLayout* inputLayout_;
        ID3D11Buffer* vertexBuffer_;

        ID3D11Buffer* colorCB_;
        int selectedColor_;
};

We will use a constant buffer in the HLSL shader code to store the color value with which we want to shade the surface. A constant buffer, like all DirectX 11 buffers, is of the type ID3D11BUFFER, and it is created in the LoadContent function. The only new code in the LoadContent function is the creation of the constant buffer, which can be seen in Listing 5.2.

bool KeyboardDemo::LoadContent( )
{
    // . . .Code from the Triangle demo. . .

    d3dResult = d3dDevice_->CreateBuffer( &vertexDesc,
        &resourceData, &vertexBuffer_ );

    if( FAILED( d3dResult ) )
    {
        return false;
    }

        D3D11_BUFFER_DESC constDesc;
        ZeroMemory( &constDesc, sizeof( constDesc ) );
        constDesc.BindFlags = D3D11_BIND_CONSTANT_BUFFER;
        constDesc.ByteWidth = sizeof( XMFLOAT4 );
        constDesc.Usage = D3D11_USAGE_DEFAULT;

        d3dResult = d3dDevice_->CreateBuffer( &constDesc, 0, &colorCB_ );
        if( FAILED( d3dResult ) )
    {
        return false;
    }

    return true;
}

As mentioned in Chapter 3, a constant buffer is created by setting the buffer descriptor’s BindFlags member to D3D11_BIND_CONSTANT_BUFFER. Although we could initially set the data of the constant buffer, we pass null to CreateBuffer because we’ll fill it in during the Render function. Also, we need to release the data held by the constant buffer when the application exits, which is done in the Unload function seen in Listing 5.3.

void KeyboardDemo::UnloadContent( )
{
    if( customColorVS_ ) customColorVS_->Release( );
    if( customColorPS_ ) customColorPS_->Release( );
    if( inputLayout_ ) inputLayout_->Release( );
    if( vertexBuffer_ ) vertexBuffer_->Release( );
    if( colorCB_ ) colorCB_->Release( );

    customColorVS_ = 0;
    customColorPS_ = 0;
    inputLayout_ = 0;
    vertexBuffer_ = 0;
    colorCB_ = 0;
}

The colors we are using are red, green, and blue for the shape. The Update function is responsible for determining whether the up or down arrow key was pressed and for setting the selectedColor_ class variable to either 0 (red), 1 (green), or 2 (blue). There are also conditional statements in place to ensure that the selectedColor_ class variable stays within the 0-2 range. The Update function can be seen in Listing 5.4.

void KeyboardDemo::Update( float dt )
{
    keyboardDevice_->GetDeviceState( sizeof( keyboardKeys_ ),
        ( LPVOID )&keyboardKeys_ );

    // Button press event.
    if( GetAsyncKeyState( VK_ESCAPE ) )
    {
        PostQuitMessage( 0 );
    }

    // Button up event.
     if(KEYDOWN( prevKeyboardKeys_, DIK_DOWN ) &&
       !KEYDOWN( keyboardKeys_, DIK_DOWN ) )
    {
        selectedColor_–;
    }

    // Button up event.
     if(KEYDOWN( prevKeyboardKeys_, DIK_UP ) &&
       !KEYDOWN( keyboardKeys_, DIK_UP ) )
    {
        selectedColor_++;
    }

    memcpy( prevKeyboardKeys_, keyboardKeys_, sizeof( keyboardKeys_ ) );

    if( selectedColor_ < 0 ) selectedColor_ = 2;
    if( selectedColor_ > 2 ) selectedColor_ = 0;
}

A key can be either up, pressed, pushed, or released. Although they seem similar, they are not. When a button is up, that means it is not being pressed. When a button is being pressed, that means it is being held down. When a button is pushed, that means it was pressed once but is not being held down. And when a button is released, that means it was down (pushed or being pressed) but now is up.

This is important when detecting button input from any device. In a game, if the player needs to hold down a button to perform some action, such as the acceleration button in a racing game, then we need to know whether the button is pressed or not. If the player has to press the button each time the action needs to occur, such as shooting the DMR weapon in Bungie’s Halo Reach, then we don’t want it to respond to the button being pressed, but instead we only want it to respond when it was pushed once.

Testing whether a button is up is simply a matter of “if it is not down, then it is up.” To test whether a button is in a pressed state, we have to look at the current state of the button and the previous state. If the previous state of the button was down, and if the current state of the button is down (or you can say still down), then the button is being pressed.

To test if the button was pressed once, we look to see if the previous state of the button was up and the current state of the button is down. If so, then we have a single pushed event. During the next frame, if the button is still down, the state switches from pushed to pressed. This means that pushed would only count once until the player releases the button and pushes it again.

And finally, to test if the button was released, we need to see if the previous state of the button was down and the current state of the button is up. If so, we know that button was down, and now it is up. This will only occur once because in the next frame the previous and current states will both equal up.

In the Update function in Listing 5.4 we only want to change colors when the user has released one of the arrow keys. If we simply checked if the button was down, then the color will rapidly change each frame faster than we can keep up with.

The last demo class level function is the Render function. In this function we simply fill the constant buffer with the color of red if selectedColor_ is 0, green if it is 1, and blue if it is 2. The Render function can be seen in Listing 5.5. The content of the constant buffer is updated with a call to the Direct3D context’s UpdateSubresource function.

void KeyboardDemo::Render( )
{
    if( d3dContext_ == 0 )
        return;

    float clearColor[4] = { 0.0f, 0.0f, 0.25f, 1.0f };
    d3dContext_->ClearRenderTargetView( backBufferTarget_, clearColor );
    unsigned int stride = sizeof( VertexPos );
    unsigned int offset = 0;

    d3dContext_->IASetInputLayout( inputLayout_ );
    d3dContext_->IASetVertexBuffers( 0, 1, &vertexBuffer_, &stride, &offset );
    d3dContext_->IASetPrimitiveTopology(D3D11_PRIMITIVE_TOPOLOGY_
TRIANGLELIST);

    XMFLOAT4 redColor( 1.0f, 0.0f, 0.0f, 1.0f );
    XMFLOAT4 greenColor( 0.0f, 1.0f, 0.0f, 1.0f );
    XMFLOAT4 blueColor( 0.0f, 0.0f, 1.0f, 1.0f );

    if( selectedColor_ == 0 )
    {
        d3dContext_->UpdateSubresource( colorCB_, 0, 0, &redColor, 0, 0 );
    }
    else if( selectedColor_ == 1 )
    {
        d3dContext_->UpdateSubresource( colorCB_, 0, 0, &greenColor, 0, 0 );
    }
    else
    {
        d3dContext_->UpdateSubresource( colorCB_, 0, 0, &blueColor, 0, 0 );
    }

    d3dContext_->VSSetShader( customColorVS_, 0, 0 );
    d3dContext_->PSSetShader( customColorPS_, 0, 0 );
    d3dContext_->PSSetConstantBuffers( 0, 1, &colorCB_ );
    d3dContext_->Draw( 3, 0 );

    swapChain_->Present( 0, 0 );
}

The shader for this demo can be found in a file called CustomColor.hlsl. Constant buffers in HLSL are defined in a special structure denoted by the keyword cbuffer, and it is registered to inputs starting at b0 (remember that textures were registered using t0 and shader resource views with s0).

All variables and objects within a constant buffer can be used as if they are regular global variables. In the Keyboard demo’s shader we create a variable named col that is defined within the constant buffer and that will hold the incoming color value. In the pixel shader we simply return this variable, and the custom color we set on the application side is applied to the rendering. The shader can be seen in Listing 5.6.

cbuffer cbChangesPerFrame : register( b0 )
{
    float4 col;
};


float4 VS_Main( float4 pos : POSITION ) : SV_POSITION
{
    return pos;
}


float4 PS_Main( float4 pos : SV_POSITION ) : SV_TARGET
{
    return col;
}

The last new code to examine is the code related to setting up and releasing DirectInput, which is done in the DX11DemoBase header and source files with the Direct3D code. In the DX11DemoBase.h header file, we create new objects for DirectInput and the DirectInput keyboard as seen in Listing 5.7. We also create two 256-size arrays, with one being used for the current keyboard state and the other being used for the previous state.

#define KEYDOWN(name, key) ( name[key] & 0x80 )


class Dx11DemoBase
{
    public:
        Dx11DemoBase();
        virtual ~Dx11DemoBase();
        bool Initialize( HINSTANCE hInstance, HWND hwnd );
        void Shutdown( );

        bool CompileD3DShader( char* filePath, char* entry,
                             char* shaderModel, ID3DBlob** buffer );

        virtual bool LoadContent( );
        virtual void UnloadContent( );

        virtual void Update( float dt ) = 0;
        virtual void Render( ) = 0;

    protected:
        HINSTANCE hInstance_;
        HWND hwnd_;

        D3D_DRIVER_TYPE driverType_;
        D3D_FEATURE_LEVEL featureLevel_;

        ID3D11Device* d3dDevice_;
        ID3D11DeviceContext* d3dContext_;
        IDXGISwapChain* swapChain_;
        ID3D11RenderTargetView* backBufferTarget_;

        LPDIRECTINPUT8 directInput_;
        LPDIRECTINPUTDEVICE8 keyboardDevice_;
        char keyboardKeys_[256];
        char prevKeyboardKeys_[256];
};

The code to initialize DirectInput is done in the Initialize function of the demo’s base class. This new code was added to the end of the function after the creation of the viewport, which can be seen in Listing 5.8.

bool Dx11DemoBase::Initialize( HINSTANCE hInstance, HWND hwnd )
{
    // . . .  Previous code . . .

    ZeroMemory( keyboardKeys_, sizeof( keyboardKeys_ ) );
    ZeroMemory( prevKeyboardKeys_, sizeof( prevKeyboardKeys_ ) );

    result = DirectInput8Create( hInstance_, DIRECTINPUT_VERSION,
        IID_IDirectInput8, ( void** )&directInput_, 0 );

    if( FAILED( result ) )
    {
        return false;
    }

    result = directInput_->CreateDevice(GUID_SysKeyboard, &keyboard
Device_, 0);

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->SetDataFormat( &c_dfDIKeyboard );

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->SetCooperativeLevel( hwnd_, DISCL_FOREGROUND |
        DISCL_NONEXCLUSIVE );

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->Acquire( );

    if( FAILED( result ) )
    {
        return false;
    }

    return LoadContent( );
}

And last but not least we must release DirectInput and the keyboard device, which is done in the base class’ Shutdown function in Listing 5.9.

void Dx11DemoBase::Shutdown( )
{
    UnloadContent( );

    if( backBufferTarget_ ) backBufferTarget_->Release( );
    if( swapChain_ ) swapChain_->Release( );
    if( d3dContext_ ) d3dContext_->Release( );
    if( d3dDevice_ ) d3dDevice_->Release( );

    if( keyboardDevice_ )
    {
        keyboardDevice_->Unacquire( );
        keyboardDevice_->Release( );
    }

    if( directInput_ ) directInput_->Release( );

    backBufferTarget_ = 0;
    swapChain_ = 0;
    d3dContext_ = 0;
    d3dDevice_ = 0;
    keyboardDevice_ = 0;
    directInput_ = 0;
}

Reading input from the mouse is very similar to reading it from the keyboard. The main difference is the GUID passed to the CreateDevice function and the DIDATAFORMAT structure used to hold the input for this device.

In the previous example, the call to CreateDevice used GUID_SysKeyboard as the first parameter. When using the mouse, the GUID for CreateDevice must be set to GUID_SysMouse.

hr = directInputObject->CreateDevice( GUID_SysMouse, &mouseDevice, 0 );

if( FAILED( hr ) )
{
    return FALSE;
}

Also, the call to SetDataFormat used the predefined data format c_dfDIKeyboard. This value must be changed to c_dfDIMouse when using the mouse as the input device.

hr = mouseDevice->SetDataFormat( &c_dfDIMouse );

if( FAILED( hr ) )
{
    return FALSE;
}

The final change that needs to be made before you can read from the mouse is the addition of the DIDATAFORMAT buffer. The keyboard needs a character buffer consisting of 256 elements, whereas the mouse needs a buffer of type DIMOUSESTATE.

The DIMOUSESTATE structure consists of three variables holding the X, Y, and Z positions of the mouse as well as a BYTE array of four elements for holding the state of the mouse buttons. The DIMOUSESTATE structure is defined as:

typedef struct DIMOUSESTATE {
    LONG lX;
    LONG lY;
    LONG lZ;
    BYTE rgbButtons[4];
} DIMOUSESTATE, *LPDIMOUSESTATE;

Previously, a macro was used to help determine if specific keys on the keyboard had been pressed. A similar macro can be used to check the state of the mouse buttons.

The X, Y, and Z values in the DIMOUSESTATE structure do not hold the current position of the mouse but rather the relative position to where the mouse previously was. For example, if you moved the mouse slightly to the left about 5 pixels, the X value would be —5. If you moved the mouse down 10 pixels, the Y value would be 10.

When reading from a mouse, you must keep track of the values read from the mouse on the previous frame to be able to correctly interpret the mouse movement.

The following code fragment demonstrates the code needed to read from the mouse device. This code handles checking both the movement of the mouse as well as the state of the mouse buttons. In the code fragment we use a custom macro called BUTTONDOWN to test the DIMOUSESTATE to determine if it is pressed. Alternatively, if support for a four-button mouse is needed, then the DIMOUSESTATE2 structure can provide the necessary data.

#define BUTTONDOWN(name, key) ( name.rgbButtons[key] & 0x80 )

curX = 320;
curY = 240;

while ( 1 )
{
    mouseDevice->GetDeviceState( sizeof ( mouseState ), (LPVOID) &mouseState );

    if( BUTTONDOWN( mouseState, 0 ) )
    {
        // Do something with the first mouse button
    }
    if( BUTTONDOWN( mouseState, 1 ) )
    {
        // Do something with the up arrow
    }

    curX += mouseState.lX;
    curY += mouseState.lY;
}

The Mouse demo can be found on the companion website in the Chapter5/ Mouse folder. The demo builds off of the Keyboard demo but adds a mouse device. This code is essentially the keyboard device code copied and pasted underneath. The only change is to change the keyboard-specific flags to mouse-specific flags, such as changing c_dfDIKeyboard to c_dfDIMouse.

Listing 5.10 has the Update function from the Mouse demo. The lZ member of the mouse state holds the mouse wheel value. If the mouse does not have a mouse wheel, this value will remain 0. You can increase or decrease this value to indicate which direction the mouse wheel has moved, whereas the lX and lY represent the X and Y mouse position changes.

void MouseDemo::Update( float dt )
{
    keyboardDevice_->GetDeviceState( sizeof( keyboardKeys_ ),
        ( LPVOID )&keyboardKeys_ );

    mouseDevice_->GetDeviceState( sizeof ( mouseState_ ),
        ( LPVOID ) &mouseState_ );

    // Button press event.
    if( GetAsyncKeyState( VK_ESCAPE ) )
    {
        PostQuitMessage( 0 );
    }

    // Button up event.
    if( KEYDOWN( prevKeyboardKeys_, DIK_DOWN ) &&
       !KEYDOWN( keyboardKeys_, DIK_DOWN ) )
    {
        selectedColor_—;
    }

    // Button up event.
    if( KEYDOWN( prevKeyboardKeys_, DIK_UP ) &&
      ;!KEYDOWN( keyboardKeys_, DIK_UP ) )
    {
        selectedColor_++;
    }

    if( BUTTONDOWN( mouseState_, 0 ) && !BUTTONDOWN( prevMouseState_, 0 ) )
    {
        selectedColor_++;
    }

    if( BUTTONDOWN( mouseState_, 1 ) && !BUTTONDOWN( prevMouseState_, 1 ) )
    {
        selectedColor_—;
    }

    mousePosX_ += mouseState_.lX;
    mousePosY_ += mouseState_.lY;
    mouseWheel_ += mouseState_.lZ;


    memcpy( prevKeyboardKeys_, keyboardKeys_, sizeof( keyboardKeys_ ) );
    memcpy( &prevMouseState_, &mouseState_, sizeof( mouseState_ ) );

    if( selectedColor_ < 0 ) selectedColor_ = 2;
    if( selectedColor_ > 2 ) selectedColor_ = 0;
}

The code that creates the keyboard and mouse device, and the code that includes the release of the mouse device, can be seen in Listing 5.11. The code to set up the mouse, as you can see, is nearly identical to that of the keyboard.

bool Dx11DemoBase::Initialize( HINSTANCE hInstance, HWND hwnd )
{
    // . . .Previous code. . .

    ZeroMemory( keyboardKeys_, sizeof( keyboardKeys_ ) );
    ZeroMemory( prevKeyboardKeys_, sizeof( prevKeyboardKeys_ ) );

    result = DirectInput8Create( hInstance_, DIRECTINPUT_VERSION,
        IID_IDirectInput8, ( void** )&directInput_, 0 );

    if( FAILED( result ) )
    {
        return false;
    }

    result = directInput_->CreateDevice(GUID_SysKeyboard, &keyboardDevice_,
0);

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->SetDataFormat( &c_dfDIKeyboard );

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->SetCooperativeLevel( hwnd_,
        DISCL_FOREGROUND | DISCL_NONEXCLUSIVE );

    if( FAILED( result ) )
    {
        return false;
    }

    result = keyboardDevice_->Acquire( );
    if( FAILED( result ) )
    {
        return false;
    }

    mousePosX_ = mousePosY_ = mouseWheel_ = 0;

    result = directInput_->CreateDevice( GUID_SysMouse, &mouseDevice_, 0 );

    if( FAILED( result ) )
    {
        return false;
    }

    result = mouseDevice_->SetDataFormat( &c_dfDIMouse );

    if( FAILED( result ) )
    {
        return false;
    }

    result = mouseDevice_->SetCooperativeLevel( hwnd_,
        DISCL_FOREGROUND | DISCL_NONEXCLUSIVE );

    if( FAILED( result ) )
    {
        return false;
    }

    result = mouseDevice_->Acquire( );

    if( FAILED( result ) )
    {
        return false;
    }
    return LoadContent( );
}

void Dx11DemoBase::Shutdown( )
{
    UnloadContent( );

    if( backBufferTarget_ ) backBufferTarget_->Release( );
    if( swapChain_ ) swapChain_->Release( );
    if( d3dContext_ ) d3dContext_->Release( );
    if( d3dDevice_ ) d3dDevice_->Release( );

    if( keyboardDevice_ )
    {
        keyboardDevice_->Unacquire( );
        keyboardDevice_->Release( );
    }

    if( mouseDevice_ )
    {
        mouseDevice_->Unacquire( );
        mouseDevice_->Release( );
    }

    if( directInput_ ) directInput_->Release( );

    backBufferTarget_ = 0;
    swapChain_ = 0;
    d3dContext_ = 0;
    d3dDevice_ = 0;
    keyboardDevice_ = 0;
    mouseDevice_ = 0;
    directInput_ = 0;
}

DirectInput had a lot of setup code for the simple tasks it performed. In XInput we technically don’t have any special initialization code. We can check whether or not an Xbox 360 controller is attached to the machine by calling the function XInputGetState. The XInputGetState function has the following function prototype:

DWORD XInputGetState(
    DWORD dwUserIndex,
    XINPUT_STATE* pState
);

The XInputGetState function takes as parameters the player index and the out address of the XINPUT_STATE object that will store the state. The player index is zero based, so a value of 0 is for player 1, a value of 1 is for player 2, a value of 2 is for player 3, and a value of 3 is for player 4. The controller will have a light around the Xbox 360 guide button that indicates which player it is connected to. By calling XInputGetState with a player index, we will receive a return value of ERROR_SUCCESS if the controller is plugged in. If the return value is ERROR_DEVI-CE_NOT_CONNECTED, then the controller is not plugged in. Any other return value and there is a problem with the device or obtaining its state.

Although we don’t have to set up XInput, we could opt to disable it. This is done with a call to XInputEnable, which is used for situations when the application loses focus (which can occur if the application is minimized). The function XInputEnable takes a single parameter, which is a flag to enable or disable XInput. False disables XInput while true enables it. When disabled, XInputGet State returns neutral data as if all buttons are up and no input is occurring. The function prototype for XInputEnable has the following look:

void XInputEnable( BOOL enable );

Many Xbox 360 controllers have force feedback capabilities. For game pads this occurs via a left and right motor in the controller that causes the device to vibrate. To turn on the controller vibration, we must send to the controller the vibration state with a call to XInputSetState. XInputSetState has the following function prototype:

DWORD XInputSetState(
    DWORD dwUserIndex,
    XINPUT_VIBRATION* pVibration
);

The first parameter to the XInputSetState function is a 0-3 player index for players 1, 2, 3, or 4. The second parameter is a XINPUT_VIBRATION object, which has the following structure:

typedef struct _XINPUT_VIBRATION {
    WORD wLeftMotorSpeed;
    WORD wRightMotorSpeed;
} XINPUT_VIBRATION, *PXINPUT_VIBRATION;

The wLeftMotorSpeed is used to set the left motor’s speed and the wRightMo torSpeed is used to set the right motor’s speed. The values for the motor speeds range between 0 and 65,535, where 0 is no speed and 65,535 is 100% power.

With a call to XInputGetState we have all the information about the current state of a controller device. The last parameter of the XInputGetState function was an out address to an XINPUT_STATE structure object that contained an XINPUT_GAMEPAD structure with the following structure:

typedef struct _XINPUT_GAMEPAD {
    WORD wButtons;
    BYTE bLeftTrigger;
    BYTE bRightTrigger;
    SHORT sThumbLX;
    SHORT sThumbLY;
    SHORT sThumbRX;
    SHORT sThumbRY;
} XINPUT_GAMEPAD, *PXINPUT_GAMEPAD;

The wButtons is a bitmask value, meaning that each button can be tested by using bit operators. There are flags for the arrow pad buttons, the joystick buttons, the face buttons (buttons A, B, X, and Y), shoulder buttons LB and RB, and the start and select buttons. The joystick buttons are L3 for the left stick and R3 for the right stick, and they are pressed by pushing the joysticks inward. We’ll show how to detect input from face buttons during the XInput demo.

The bLeftTrigger is used for the left trigger button (on top of the game pad controller), and the bRightTrigger is used for the right trigger. These values range between 0 and 255, where 0 is not pressed, 255 is pressed fully down, and anything between represents how much the trigger is being pressed.

The sThumbLX, sThumbLY, sThumbRX, and sThumbRY values are used for the left and right joystick positions. These values range between —32,768 and 32,767 where, for example, —32,768 for the left stick’s X-axis represents the stick being moved all the way to the left, and +32,767 represents that it is pressed all the way to the right.

The XINPUT_GAMEPAD structure will give us all the information needed to detect and respond to input using Xbox 360 game controllers.

Sometimes we might need to know the capabilities of a connected device. This can be achieved with a call to XInputGetCapabilities, which has the following prototype:

DWORD XInputGetCapabilities(
    DWORD dwUserIndex,
    DWORD dwFlags,
    XINPUT_CAPABILITIES* pCapabilities
);

The function XInputGetCapabilities takes as parameters the player index, the device search flags, and an out address to the structure that holds the device’s capabilities. For the flags we can specify a value of 0 for all device types (e.g., game pads, steering wheels, etc.), or we can specify XINPUT_FLAG_GAMEPAD to limit the search to just game pads. Currently XINPUT_FLAG_GAMEPAD is the only flag supported.

The capabilities are stored in the XINPUT_CAPABILITIES object, which has the following structure:

typedef struct _XINPUT_CAPABILITIES {
    BYTE Type;
    BYTE SubType;
    WORD Flags;
    XINPUT_GAMEPAD Gamepad;
    XINPUT_VIBRATION Vibration;
} XINPUT_CAPABILITIES, *PXINPUT_CAPABILITIES;

The first member is the type of device, which currently will only be XINPUT_DEVTYPE_GAMEPAD.

The second member is the subtype that can further define what type of device it is and can be XINPUT_DEVSUBTYPE_ARCADE_STICK, XINPUT_DEVSUB TYPE_GAMEPAD, or XINPUT_DEVSUBTYPE_WHEEL. If the device is not a game pad, arcade stick, or steering wheel, it should be treated as if it is just a game pad.

The GAMEPAD member will store the button state of the game pad and the last member, the VIBRATION member, will store the current motor speeds of the device.

Xbox controllers that are wireless devices can have their battery information obtained via XInput. This is accomplished with a call to the function XInput GetBatteryInformation, which has the following function prototype:

DWORD XInputGetBatteryInformation(
    DWORD dwUserIndex,
    BYTE devType,
    XINPUT_BATTERY_INFORMATION* pBatteryInformation
);

The first parameter to the XInputGetBatteryInformation function is the player index, the second parameter is the device type (0 for all types of devices or XINPUT_FLAG_GAMEPAD), and the last parameter is the out address to the XINPUT_BATTERY_INFORMATION object that will store the battery information. The XINPUT_BATTERY_INFORMATION has the following structure:

typedef struct _XINPUT_BATTERY_INFORMATION {
    BYTE BatteryType;
    BYTE BatteryLevel;
} XINPUT_BATTERY_INFORMATION, *PXINPUT_BATTERY_INFORMATION;

The BATTERYTYPE member can be one of the following values:

The BATTERYLEVEL value can be one of the following:

XInput provides a more general method of obtaining input rather than using XInputGetState via a function called XInputGetKeystroke. This function is used to obtain an input event for a connected game pad. The XInputGetKeyStroke has the following prototype:

DWORD XInputGetKeystroke(
    DWORD dwUserIndex,
    DWORD dwReserved,
    PXINPUT_KEYSTROKE pKeystroke
);

The first member is the player index, the second member is the device type we are querying for (either 0 or XINPUT_FLAG_GAMEPAD), and the third member is the out address to the keystroke event. The PXINPUT_KEYSTROKE has the following structure:

typedef struct _XINPUT_KEYSTROKE {
    WORD VirtualKey;
    WCHAR Unicode;
    WORD Flags;
    BYTE UserIndex;
    BYTE HidCode;
} XINPUT_KEYSTROKE, *PXINPUT_KEYSTROKE;

The virtual key code (VirtualKey) of the XINPUT_KEYSTROKE structure will store the ID of the button that triggered the event.

The second member is unused and is always 0.

The third member is the flag that triggered the event. This flag can be XINPUT_KEYSTROKE_KEYDOWN if the button was pushed, XI NPUT_ KEYSTROKE_KEYUP if the button was released, and XI NPUT_KEYSTROKE_REPEAT if the button is being held down.

The fourth member is the player index from 0 to 3 that caused the event, and the last parameter is an HID code value that future devices might return.

Many Xbox 360 controllers have a port for the inclusion of an Xbox 360 headset. This headset is primarily used for player-to-player communications over Xbox LIVE, the online community and service Microsoft provides for the Xbox 360 game console (the Windows equivalent is Games for Windows LIVE). In XInput we could use the headset’s speaker for audio output and its microphone for audio input with the help of the XInputGetDSoundAudioDeviceGuids function, which has the following prototype:

DWORD XInputGetDSoundAudioDeviceGuids(
    DWORD dwUserIndex,
    GUID* pDSoundRenderGuid,
    GUID* pDSoundCaptureGuid
);

The first member is the player index, the second member is the DirectSound rendering GUID, and the third member is the DirectSound capturing GUID. The GUID is for the headset device rendering (playing) or capturing sound. A headset has both a microphone for sound recording and a speaker for sound playback, and these two devices exist within all standard Xbox 360 headsets.

Using this to work with controller headsets requires knowledge of DirectSound, which is a deprecated audio API in DirectX. The DirectX SDK has samples for using DirectSound with XInput to capture headset audio.

The XInput demo, which demonstrates how to detect and respond to game controller button input, can be found on the companion website in the Chapter5/XInput folder. This demo is exactly the same as the Keyboard and Mouse demos, and the Xinput-specific code can be found in the demo’s Update function. Since XInput does not need to be explicitly initialized like DirectInput, all of this demo’s specific code takes place in a single function.

The XInput demo class from XInputDemo.h can be seen in Listing 5.12. Like the previous input demos, we store the previous and current device states to use the combination to detect key up events.

#include"Dx11DemoBase.h"
#include<XInput.h>


class XInputDemo : public Dx11DemoBase
{
    public:
        XInputDemo( );
        virtual ~XInputDemo( );

        bool LoadContent( );
        void UnloadContent( );

        void Update( float dt );
        void Render( );

    private:
        ID3D11VertexShader* customColorVS_;
        ID3D11PixelShader* customColorPS_;

        ID3D11InputLayout* inputLayout_;
        ID3D11Buffer* vertexBuffer_;

              ID3D11Buffer* colorCB_;
              int selectedColor_;

        XINPUT_STATE controller1State_;
        XINPUT_STATE prevController1State_;
};

The Update function starts by obtaining the current device state. If the return value of XInputGetState is ERROR_SUCCESS, then the state was obtained successfully, and we know that device slot 0, which is player 1, has a device plugged in.

The demo uses the back button on the controller to exit the application. The demo also uses the face buttons to switch the colors, where the X button switches to blue, the A button switches to green, and the B button switches to red. The triggers in the demo are used to control the left and right motors for vibration. The more you press the triggers, the harder the device will vibrate.

The Update function can be seen in Listing 5.13.

void XInputDemo::Update( float dt )
{
    unsigned long result = XInputGetState( 0, &controller1State_ );
    if( result == ERROR_SUCCESS )
    {

    }

    // Button press event.
    if( controller1State_.Gamepad.wButtons & XINPUT_GAMEPAD_BACK )
      {
          PostQuitMessage( 0 );
      }

    // Button up event.
    if( ( prevController1State_.Gamepad.wButtons & XINPUT_GAMEPAD_B ) &&
        !( controller1State_.Gamepad.wButtons & XINPUT_GAMEPAD_B ) )

      {
           selectedColor_ = 0;
      }

   // Button up event.
   if( ( prevController1State_.Gamepad.wButtons & XINPUT_GAMEPAD_A ) &&
       !( controller1State_.Gamepad.wButtons & XINPUT_GAMEPAD_A ) )

     {
          selectedColor_ = 1;
     }

   // Button up event.
   if( ( prevController1State_.Gamepad.wButtons & XINPUT_GAMEPAD_X ) &&
       !( controller1State_.Gamepad.wButtons & XINPUT_GAMEPAD_X ) )
     {
          selectedColor_ = 2;
     }

XINPUT_VIBRATION vibration;
WORD leftMotorSpeed = 0;
WORD rightMotorSpeed = 0;

float leftTriggerVal = ( float )controller1State_.Gamepad.bLeftTrigger;
float rightTriggerVal = ( float )controller1State_.Gamepad.bRightTrigger;
    if( controller1State_.Gamepad.bLeftTrigger > 0 )
      {
        leftMotorSpeed = ( WORD )( 65535.0f * ( leftTriggerVal / 255.0f ) );
      }

    if( controller1State_.Gamepad.bRightTrigger > 0 )
      {
        rightMotorSpeed = ( WORD )( 65535.0f * ( rightTriggerVal / 255.0f ) );
      }

    vibration.wLeftMotorSpeed = leftMotorSpeed;
    vibration.wRightMotorSpeed = rightMotorSpeed;

    XInputSetState( 0, &vibration );

    memcpy( &prevController1State_, &controller1State_, sizeof(XINPUT_STATE) );
}