The three different APIs for using Touch in Windows* Desktop are: WM_GESTURE, WM_TOUCH, and WM_POINTER. They are all different, each with its own advantages and disadvantages. WM_POINTER is the most recent API, but it only works with Windows 8. WM_GESTURE and WM_TOUCH were both introduced with Windows 7 and maintain compatibility in Windows 8. Because backwards compatibility is so important to game developers, we expect most developers will opt to go for one of these two APIs.
WM_GESTURE is the simplest API to get up and working. The developer doesn’t have to do anything in particular to start receiving gestures other than handle the relevant messages. The gestures are pre-defined by Microsoft and aren’t customizable, but they will give useful data from the start. The gestures are defined here.
WM_TOUCH is the more advanced API that gives the developer full power (and responsibility) over how the user interacts with the application. Whereas WM_GESTURE gives the developer information about whatever gesture the user is trying to do, WM_TOUCH only gives the raw touch points. If the developer wants to support a gesture like pinch-to-zoom, they must manually determine what gesture the user is doing. The OS doesn’t give the developer any help. However, the developer is free to develop their own custom gestures.
One important thing to note is that WM_TOUCH and WM_GESTURE are mutually exclusive. Only one of the APIs can be active at a time. A developer can’t choose to use WM_GESTURE for the “basic” gestures and then use WM_TOUCH only for their custom ones—it’s all or nothing. For a simple casual game or any game that has minimal needs for a touch API, WM_GESTURE would probably be the way to go. The small amount of lag inherent when using WM_GESTURE isn’t a problem for most casual uses. It’s easy to set up and can give instant results. WM_TOUCH should be used when the developer has more custom needs for touch or requires more responsive controls. However, the amount of extra effort required to use WM_TOUCH is not insignificant. The developer will have to define and tweak the behavior for every gesture they want to support in their app.
This sample demonstrates one way to implement WM_TOUCH support. We added feature parity with the WM_GESTURE API, so you can toggle between the two APIs and see the difference in their responsiveness. We’ve also implemented a custom gesture that is completely unavailable with the WM_GESTURE API.