The Microsoft documentation defines the following three macros which can be used to ignore the mouse events which Window generates from pen devices.
#define MI_WP_SIGNATURE 0xFF515700
#define SIGNATURE_MASK 0xFFFFFF00
#define IsPenEvent(dw) (((dw) & SIGNATURE_MASK) == MI_WP_SIGNATURE)

The IsPenEvent macro will also identify mouse events Windows generates from touch devices. Using this information we were able to help a customer get touch events working in their application which uses our 2D dynamic graphics engine.

Thanks again!

?

We haven’t finished touch support yet for any platform because it requires good player pathfinding / etc through the world, and we are working on that.

Any update on this? I’ve made the increasingly questionable decision to transition from an aging but reasonably well spec-ed desktop rig to a 5 year old refurbished Windows 7 tablet as my sole pc for impending travel. I’ll have a little handheld trackball and a 360 pad with me anyway, so it certainly won’t stop me from playing the game, but I was looking forward to the tactile experience of tracing the puzzles with my finger.

Just spent hours trying to figure out why my Python / Kivy app on the Surface Pro 4 was being random and recognizing some, not other touch interactions.

Your article pointed me in the right direction for the fix. The app was trying to respond to both mouse and wm_touch messages. Disabling the app’s attempts to handle wm_touch itself allowed the touch events to be converted into mouse events and be processed properly by the app.

Thanks – extremely helpful :)

Thanks for the speedy response, can’t wait to play it using the touchscreen it seems like such a natural fit.

Touch controls are not enabled yet. We plan to turn them on before too long but for now it’s mouse/keyboard or gamepad only.

I had one further problem, which was that I want to be able to use pen input as well as mouse and touch. Pen events come through to WM_MOUSEMOVE etc marked with MOUSEEVENTF_FROMTOUCH, *but* they don’t get a WM_TOUCH event. You have to separate “from touch” events into “from pen” and “from finger”, and process pen events like a mouse. Touches from a finger have bit 0x80 set in GetMessageExtraInfo, pen messages haven’t. The lower 7 bits are the touch device id. The 0x82 you found from experimenting is presumably 0x80 plus a device id, and may not work on all machines.

It was only by working this out through trial and error that I had enough information to find this MSDN article confirming it: http://msdn.microsoft.com/en-us/library/windows/desktop/ms703320%28v=vs.85%29.aspx

thank you

We would explicitly have to turn off 360 controller support, and I can’t think of any reason we would do that (unless there were some kind of unforeseen technical problem.)

http://youtu.be/Q1ZeXnmDZMQ

Special thanks to Instigative Catwoman for sharing…
Capcha: Illustrating this

This is correct. They are part of the Win8 SDK. Once that’s publically released (or if you have MSDN) – go grab it!

From what I remember, WM_TOUCH operates a bit differently on Win8 than it did on Win7. I believe Windows cut some of the support and my project saw some interesting regressions between the two versions of the OS. I apologize though, I can’t remember exactly what it was.

This comment amuses me. Do you ever develop for Apple products? Time after time? You don’t know what you’re talking about. Just another Apple fanboy.

The point of this article was that WM_TOUCH was poorly done and the author kindly explained some hurdles he went over. I have used WM_POINT* messages extensively and they are fantastic for custom touch control.

Very interesting video, thanks for the link.

I’ve found what appears to be the WM_POINTER documentation here: http://msdn.microsoft.com/en-us/library/windows/desktop/hh454903%28v=vs.85%29.aspx
No usage guide there yet, but the video makes a good introduction (even though it does not talk about WM_POINTER much at all, and instead focuses on WinRT api’s, they are apparently designed to be analogous).

Apparently, there is not a message called WM_POINTER but a variety of message types, which is probably why I did not find this before. The extra information is retrieved by calling a function, and only information for the last returned pointer message from a specific device (and, if the message was coalesced, any events that happened between messages) is available. It does seem more intuitive.

I wouldn’t do it for an action game, but for a slower-paced game it isn’t a problem. Try downloading Epic Citadel / etc.

It works that way on Windows 7 too… you still receive the union of “pure” mouse events and touch-based ones, and it’s quite annoying. Will take a look at WM_POINTER, since in my case I’m not too concerned about the small number of Windows 7 tablet/touch devices out there.

Apportable has done a great job porting osmos to android. If you decide that it’s too much of a headache to do yourself, there are other options.

If I were you I would not be so sure of myself (seemingly to the point of rudeness as you are here).

Of course the game calls RegisterTouchWindow, because if you don’t call this, you don’t receive any touch events at all. (To verify this for the 20th time, I just tried taking out the RegisterTouchWindow call again, before writing this reply). When you do receive these touch events, it works as I have described: through mouse events. There is no apparent way not to receive the mouse events, as far as I can see.

For all I know this may be behavior specific to Windows 8. I haven’t tried it on Windows 7 yet. What I have described is merely the extremely consistent and reproducible behavior of the message system on this one Windows 8 machine that I have.

If and when the Ouya actually exists and people have bought it and are running games on it then we will look at it as a possibility.

How about OUYA? I know it isn’t released yet, but:
1. It’s has quite capable Tegra 3 GPU.
2. It’s just a single device. No diversification.
3. It’s a dedicated gaming platform, but without many quality games yet. Game as polished as The Witness will catch a lot of attention.
4. It’s essentially just a usual android device, game will work on (powerful enough) android tablets with minimal changes.

You complain that WM_TOUCH is being converted to WM_INPUT and WM_MOUSEMOTION. Obviously this is to support applications that are unaware of any WM_TOUCH events being generated. However, there’s a very simple way to work around this: register your application to receive touch!

Call “RegisterTouchWindow” (http://msdn.microsoft.com/en-us/library/windows/desktop/dd317326(v=vs.85).aspx) at the start of your application and you will receive WM_TOUCH messages without them being converted to mouse events.

Check out the development branch of GLFW that includes my patches: https://github.com/elmindreda/glfw/tree/touch. See the functions “_glfwPlatformSetTouchInput” and look for “WM_TOUCH” in “win32_window.c”.

WM_POINTER is described in the following slides/talk.

http://video.ch9.ms/build/2011/slides/APP-186T_Townsend.pptx
http://channel9.msdn.com/Events/Build/BUILD2011/APP-186T

The 50 min talk is very interesting if you enjoy the topic of input handling and touch.

I’m a huge fan of the new WM_POINTER API, it’s the best thing coming from Microsoft that I’ve seen. I highly recommend watching the above video.

I really dislike DefWindowProc in particular. It is undocumented, you don’t have access to its source code, and worst of all, it completely blocks your main (where typically your OpenGL rendering happens) thread while the user moves or resizes the window. You have no way around your main thread blocked, unless you’re willing to avoid using DefWindowProc by reimplementing all default windows behaviours (moving, resizing, minimizing, etc.), which is a lot of work and will invariably have your app acting differently from the standard Windows experience.

That said, I still think you could’ve debugged this problem faster if you had started with sample code where WM_TOUCH was being received, and changed its message loop one step at a time to be like yours and checked which change breaks WM_TOUCH being received. Or maybe it’d be slower that way, I dunno.

We will see about Android. I am not a fan of trying to build a robust experience across lots of heterogeneous unpredictable hardware-and-software profiles. But if it turns out that there are a couple of devices that are prominent and on which the game will run well, we’d probably release it.

I *believe* WM_POINTER is documented in the Windows 8 SDK that was just released in mid-August. I haven’t verified this, though.

The definitions do not exist even in the headers included with Visual Studio 2012. In order to reply to WM_POINTER messages I had to #define the constants myself, etc. (This doesn’t help so much when you want to access the structs!)

Interesting read. Thanks for posting this for others to learn from. I hope that MS fixes this insanity before I have to deal with it, but somehow I doubt that’ll be the case. ;)

Because WM_INPUT is not a sent message, windows doesn’t know when you’re done processing it, and therefore it cannot know when it’s safe to free the information attached to it. In theory, you could save them up and process them in batches. I don’t know why anyone would do that, but it’s possible. (And, if MS were to free the handle on the next GetMessage call in the thread, anyone who tried to batch process them would likely have a similar reaction to the resulting confusing behavior.)

Of course, given that you have to opt into WM_TOUCH, I don’t know why they didn’t just put it in the thread input queue and skip the corresponding WM_MOUSEMOVE/WM_INPUT messages. That would add a similar requirement to the one you have with WM_INPUT – since it would not be a posted message, and would have to contain more than 2 pointers worth of data, you’d need to call some other function to free the extra data.

Incidentally, where is WM_POINTER documented? I’m interested in how they designed that differently, and I don’t see it anywhere on MSDN.