Game Development Reference
In-Depth Information
So, why is this acquisition mechanism needed? Firstly, DirectInput needs a way to
tell our application if the flow of data from a device has been interrupted by the sys-
tem. This would happen, for example, if the user switches to another application win-
dow using
Alt
+
Tab
and uses the same input device in that application.
The second reason this acquisition mechanism is needed is because our program
can change the properties of a device. DirectInput requires us to release the device
before changing its properties. This is done by calling its
Unacquire()
method.
Then you would reacquire it once you've finished changing its properties. This en-
sures that the device is not being used when we're changing its properties as this
could cause serious problems. Note that there is one exception to this rule, which is
that you can change the gain of a force feedback device while it is acquired.
Back to our code. The next two lines update our keyboard state variables. First,
the keyboard state that was current for the previous frame is copied from the
m_KeyboardStateCurrent
member variable into the
m_KeyboardStateLast
member variable. Then, we get the current keyboard state and store it in our
m_KeyboardStateCurrent
member variable.
The last two lines do the same thing, but with our mouse state member variables.
The IDisposable interface
As you'll recall from earlier in this chapter, we changed the declaration of the
User-
Input
class to make it implement the
IDisposable
interface. We covered this in-
terface in
Chapter 1
,
Getting Started
.
As you may recall, we must implement two methods. The
public void Dis-
pose()
method is identical to the one we created in our
GameWindow
class. So, I
will not show it here. On the other hand, the
protected void Dispose(bool)
method is different. Here is its code:
protected virtual void Dispose(bool disposing)
{
if (!this.m_IsDisposed)
{
if (disposing)
