In DirectInput, the device control has been obtained after Acquire, so why do you need to poll one more step? And what is the order of polling and acquire? I, who have never understood this, checked MSDN and finally understood the meaning of this polling. The original MSDN text is as follows:
Again, the translation is as follows:
Get data from the device being polled on a DirectInput device. If the device has not requested polling, calling this method has no effect. If a device requesting polling is not periodically polled, no new data will be received from the device. Calling this method causes DirectInput to update the device state, generate input events (if buffer data is available), and set notification events (if notifications are available).
return value
The return value is DI_OK if the method is successful, or DI_NOEFFECT if the device has not requested polling. If the call fails, the return value will be one of the following error values: DIERR_INPUTLOST, DIERR_NOTACQUIRED, DIERR_NOTINITIALIZED.
Notice:
Before a device's data can be polled, its data format must be set by using the IDirectInputDevice8::SetDataFormat or IDirectInputDevice8:SetActionMap methods, and the device must be acquired by using the IDirectInputDevice8 interface method.
In addition, let's talk about the role of polling in the operating system: roughly speaking, the cpu asks the peripheral whether there is a polling request (such as data needs to be updated) by accessing the peripheral, and if necessary, the latest updated peripheral The state is saved to the system's own buffer. And we need to use the IDirectInputDevice8::GetDeviceState method to tell the operating system to copy the data of the system buffer that holds the latest state of the peripheral into the buffer passed in by itself.
So here it becomes very clear. In order, it must be Acquire first and then Poll. The reason is that as mentioned in the Remarks on MSDN, before the device data is polled, it must be acquired (acquire).