Implement Microsoft.Xna.Framework.Input.Touch about fna

[flibitijibibo]

I just added a new-from-scratch version of the Touch namespace to FNA:

4d2c3ed

For now this just works as the Touch namespace would for XNA 4.0, where it's just a giant stub. However, I'd sprinkled a few TODOs and FIXMEs within the above commit as a possible guide as to how this might be implemented officially.

My expectation is that the Touch namespace won't actually change all that much aside from a couple accuracy fixes and a static method in TouchPanel.cs that figures out how the crap Gestures are calculated. What probably will change is the addition of a couple FNAPlatform methods, as well as the addition of SDL_Touch event handling in SDL2_FNAPlatform.

If iOS/Android/Switch are going to happen we should probably take this more seriously. If anyone needs a refresher on this, the MSDN sample is probably the best we have:

https://msdn.microsoft.com/en-us/library/ff434208.aspx

CC'ing @0x0ade, @clarvalon, @SeanColombo, and @ltodoto, who either talked to me about this before or, according to the Network, have forks related to Touch and/or iOS/Android support.

[flibitijibibo]

Dumping one more link in here, this provides some decent insight into how Touch should actually work, including a pretty comprehensive sample project:

https://blogs.msdn.microsoft.com/nicgrave/2010/07/12/touch-gestures-on-windows-phone-7/

SDL Switch has touch events so now there's finally a platform FNA supports that definitely needs this feature.

@nickgravelyn, do you happen to have any insight into how Gestures in particular are implemented? Were these something Phone 7 generated or were they made on the XNA side using basic touch up/down/move events?

I'm 99.999% sure we just wrapped up the native event handlers on the platform so that XNA games using gestures would match behavior with the native apps and Silverlight.

[flibitijibibo]

Dang, guess we have to come up with something that feels close enough. Sadly all SDL has is Dollar gestures and MultiGesture, which just gives radius/rotation variables without a whole lot of context.

Looking at the SDL backends for this (Wayland in particular), a possible project to rip off research is Qt:

http://doc.qt.io/qt-5/qt.html#GestureType-enum

[TheSpydog]

After a bit of research, it looks like determining the maximum touch count for a device hasn't improved much since the original discussion. Everything mentioned there is still relevant, except that I can confirm there is no public API to get the number of supported touch points on iOS. The best we could do is guesstimate based on whether the device is an iPhone (max of 5 touches) or an iPad (max of 11), but I'm not even sure those numbers are accurate for every device.

This leaves us with a few options:

1. Mimic XNA's behavior. XNA always returns 4 for MaximumTouchCount, regardless of how many touches are actually supported. Weirdly, despite this, it actually allows for a maximum of 8 touches behind the scenes.

2. Hardcode MaximumTouchCount to be 8. This is more in line with what XNA actually did. I believe this is how the original FNA-MGHistory behaved as well, for better or worse.

3. Write a patch for SDL2 that can return our best guess for supported touch points on a given device. (SDL_GetMaxTouchPoints?) This is the ideal solution, but again, for some platforms there is no supported way to get this information, and I don't want to mislead people into under- or over-estimating the capabilities of a touch device.

I'm leaning toward Option 1. Any touch device worth its salt can support at least 4 touches, and I'm not aware of any XNA games that used more than two simultaneous touches anyway. If we really wanted, we could update the MaximumTouchCount if we see that more than 4 fingers are currently on the device...but that's probably unnecessary.

[flibitijibibo]

For accuracy's sake let's go with 1, including the secret support for 8 touches. If for some reason we need to expose the internal support for 8 it'll be relatively easy to do that, but something tells me we're never going to need 11 simultaneous touches...

[TheSpydog]

Over in my fork I've managed to get standard multitouch (via TouchPanel.GetState()) working pretty much as expected, so that's cool! But now comes the fun part: gesture detection. The more I research Gestures, the more they surprise me.

The good surprise:

• With the exception of Pinch and the Drag/PinchComplete, all gestures appear to behave as if they were manipulated with a single mouse cursor. For instance, you can start a Hold gesture with one finger, quickly lift the finger and replace it with another, and the Hold gesture will still finish as if it was always held. This should simplify detection quite a bit since we don't have to support simultaneous single-touch gestures.

The bad surprises:

• The Tap/Hold gestures behave weirdly when two fingers are placed on the screen at the same time. It appears that the position of the resulting gesture is the midpoint between the two touches. After some Googling, I came across this Microsoft patent. From reading that, I'm pretty convinced that this is a limitation with the gesture detection system of WP7 -- it only allows a single touch point for gestures and tries to coerce multiple touches into one if needed. (Other than Pinch, of course. It's worth noting that this midpoint weirdness only occurs when the Pinch gesture is not enabled.)
• It looks like at least two simultaneous Pinches are allowed (with three fingers -- one finger is shared between gestures). This is probably going to be confusing to figure out how they're differentiating between unique Pinches.
• The Flick gesture uses some kind of special sauce behind the scenes to determine inertia from the initial motion. I have absolutely no idea how this is calculated. I tried several approaches to try to replicate the Delta output (e.g. averaging the velocities of the most recent touch movement events, plugging in variables into a kinematic equation, etc.) and none of them came close. If anyone has insights into the calculation, please let me know!

[flibitijibibo]

This was completed by #204!