Design a PC game, the input of the keyboard mouse is not less. Windows also provides mouse messages such as WM_LBUTTONDOWN, WM_RBUTTONUP, and keyboard input messages such as WM_KeyDown, WM_KEYUP. But DirectInput still provides support for the mouse keyboard, why DirectInput provides a more direct access to the input device. Just like we directly take over the keyboard interrupt in DOS, instead of using what hateful INT16 to handle the keyboard input (with INT16 to handle the keyboard to enter the drawback, it is especially obvious in "Jin Yong Qun Xia Chuan", the characters are in the past When you want to pull it, this is what I think is very unhappy! I think I don't have to be more than Luo).
Of course, the INT16 of Windows's keyboard message is of course a great progress (because it provides a WM_KEYUP message), but it is still insufficient in some respects. Because the message mechanism of Windows is a buffer mechanism, the unopened keyboard mouse message is placed in the buffer waiting for the next processing, so it is very important for some application software, but for the game (especially some Action game, including sports games, is a snake foot. For example, in the football game, you go to the opponent's ball - grab the ball and shoot, the shot and the long pass (big feet) always set into the same key, this seems to be a recognized standard - but At this time, the ball is just your foot, the ball directly arrived at your feet, then you have wanted to take the ball to bypass him, but your grabbing key has been pressed, because this damn buffer mechanism, first Treat this grabbing key (that is, the shooting key), so your movement has become a blind back farm (equivalent to the big feet). Can't control your own action, doing players to do this, it is really enough. Here is where the buffer mechanism is not applicable.
DirectInput provides a way to buffer and immediately access the input device. For immediate way, it is just a way to solve the above evidue. DirectInput's initialization section of the keyboard has been given in an article in the previous article. Although it is for DirectX7, there is no difference in DX8 and DX7 in the DIRECTINPUT section, and the LPDirectInput7 is changed to LPDirectINput8. LPDirectInputDevice7 is changed to LPDirectInputDevice8. There is also a little bit of need to change is the DirectInput object. Creation, DX8 Use the following function:
DirectInput8create (Hinst, DirectInput_Version, IID_IDirectInput8, (LPVOID *) & lpdi, null);
The specific parameters inside everyone can see it, I will not say much.
Let's talk about the mouse, the buffer mechanism of the mouse is still important, the mouse movement is based on the scroll count accumulation. The mouse is sampled every 8ms (anyway, the USB mouse is like this, I estimate that the general mouse is also the same), if you only get the current state, then this mouse moves too slow (should not be 8ms every 8ms in the app) The status of the mouse is called to obtain a function). The reason why DirectInput is not because of the cause of buffering, but because of my personal preferences. The general game is judged when the position of the mouse is on the edge of the screen, and if it is to scroll to this direction. I personally don't really like this approach, maybe because my hand is stupid, playing games are often inexplicably moving, which makes me feel very problem, why is the light labeled point to the screen? So I hope that the movement of the mouse is the basis for the volume screen, which is not available in the Windows message mechanism. Because in Windows's message mechanism, the application is not allowed to receive the WM_MOUSEMOVE message when the mouse is moved on the side of the screen. However, in DirectInput, you can be implemented by myself, but DirectInput is only the scroll count of the mouse, which can have no limit on the cursor position. Let's give the initialization code for the DirectInput mouse object, which can only come in this step, nothing to say.
/ / ==================================
LPDIRECTINPUT8 PDI;
LPDIRECTINPUTDEVICE8 LPMOUSE;
// Surface of the mouse cursor
LPDIRECT3DSURFACE8 LPDSCURSOR;
Handle hmouseevent;
/ / Is a symbolic type, so it can be judged whether or not the cursor is removed from the screen to determine if the volume screen is
Short mousex = fullscreen_width / 2, mousey = fullscreen_HEight / 2;
Bool inIntinput ()
{
HRESULT HRES;
HRES = DirectInput8Create (Hinst, DirectInput_Version, IID_IDirectInput8, (LPVOID *) & lpdi, null);
IF (Failed (HRES))
Return False;
HRES = LPDI-> CreateDevice (guid_sysmouse, & lpmouse, null);
IF (Failed (HRES))
Return False;
HRES = lpmouse-> setDataFormat (& C_DFDIMOUSE);
IF (Failed (HRES))
Return False;
HRES = lpmouse-> setCooperativeElevel (HmainWnd, DISCL_EXCLUSIVE | DISCL_FOREGROUND);
IF (Failed (HRES))
Return False;
HMouseEvent = CreateEvent (NULL, FALSE, FALSE, NULL);
IF (! hmouseevent)
Return False;
HRES = lpmouse-> setEventNotification (hmouseevent);
IF (Failed (HRES))
Return False;
Dipdword Dipdw; dipdw.diph.dwsize = sizeof (dipropdword);
Dipdw.diph.dwheadersize = sizeof (dipropheader);
Dipdw.diph.dwobj = 0;
Dipdw.diph.dwhow = DIPH_DEVICE;
Dipdw.dwdata = mouse_samplebuffer; // Betfined 16
HRES = lpmouse-> setProperty (Dipdw.diph);
IF (Failed (HRES))
Return False;
LPMOUSE-> acquire ();
Return True;
}
Now that we take over the mouse, then the mouse cursor's display task has also fell on our head, but I mentioned in the D3D8 entry, the display of the cursor can be supported by D3D8. Let's take a cursor:
D3DLOCKED_RECT DLR;
/ / The Surface of the cursor can only be a A8R8G8B8 format, accounting for an alpha byte and does not support translucent, really shit
HRES = LPDEVICE-> CreateImagesurface (32, 32, D3DFMT_A8R8G8B8, & LPDSCURSOR);
IF (Failed (HRES))
Return False;
HRES = LPDSCURSOR-> LOCKRECT (& DLR, NULL, 0);
IF (Failed (HRES))
Return False;
/ / Write data in Surface, don't tell me
..................
HRES = lpdscursor-> unlockRect ();
HRES = lpDevice-> setCursorproperties (0, 0, lpdscursor);
IF (Failed (HRES))
Return False;
LPDEVICE-> Showcursor (TRUE);
Next is the access to the mouse data, here I only process the movement of the mouse. Void mouseevent () {DIDEVICEOBJECTDATA OD; HRESULT HRES; DWORD COUNT; Short X = 0, Y = 0; While (1) {count = 1; hres = lpmouse-> getDeviceData (Sizeof (DIDEVICEOBJECTDATA), & OD, & Count, 0) ; If (hres == dierr_inputlost) {lpmouse-> acquire (); return;} if (failed (hres) ||! Count) Break; switch (od.dwofs) {Case Dimofs_x: x = (short) OD. DWData; Break; Case Dimofs_y: y = (short) OD.dwdata; Break; // The left button on the physical device is pressed / released, if there is any left and right exchange, Case Dimofs_Button0: Case Dimofs_Button1: IF (od.dwdata & 0x80) // button press ............ Else // button release ............}} f (x || y) {mousex = x; mousey = y; // Determine the cursor Location and whether it is full screen, etc. ............ lpDevice-> setCursorPosition (Mousex, Mousey, D3DCURSOR_IMMEDIATE_UPDATE);}} is ok, now it is over. But I personally feel a little short. If you try, you will find that the mouse moves down slower than Windows. Why? I saw an acceleration option in the Windows mouse settings, I feel that it may be due to this reason. Then simulate it. (The following only lists the changed portion of the above function)
Short Xaccel, Yaccel;
Xaccel = yaccel = 1;
While (1)
{
..........
Switch (Od.dwofs)
{
Case Dimofs_x:
x = (short) Od.dwdata * Xaccel;
Xaccel ;
Break;
Case Dimofs_y:
Y = (short) od.dwdata * yaccel;
Yaccel ;
Break;
..........
}
.........
}
After this change, the mouse moved again and smoothly.
