Handle touch events

[Schmavery]

This will probably involve changes to reasongl. What is the best api for this? Processing proper doesn't handle them afaik, but p5.js and processing.js do. http://www.bradchen.com/blog/2011/04/processing-js-touch-events

[Schmavery]

We cooould also just treat touch events as clicks.

[jaredly]

Looks like on the web, a given touch has an identifier associated with it. We should probably expose something like env.touches: Array<{id: int, x: float, y: float}>. If we wanted to get fancy, we could also include force, which ios reports, and maybe the web does too?

[Schmavery]

Right, I can imagine exposing something like this. Maybe that's all we need for a v1.

I think the question is more how we should handle the event callbacks (whether or not to add a new one), but since we've been moving away from key/mouse callbacks using functions like Env.keyPressed etc, maybe we can leave that decision for later.

[Schmavery]

Got some simple support here https://github.com/bsansouci/reasongl/commit/78995f20193557814bbe5fbdefeec270fd4da2bc. More in the works...

[RawToast]

I see you've added basic touch support to reasongl, is it likely to be ported here too? Or are they mapped to mouse events?

I've been trying to use mouse events for touch control, but they behave strangely with multi-touch as only one 'click' can be taken at a time. A simple scenario is:

• User touches and holds 'left' position
• Then presses and holds 'right'
• Then lets go of 'left'

In this scenario, the current use of mouse presses doesn't seem to register the middle 'right' press with "mouseDown" and retains its old position. Just fixing that issue might be enough for now :)

[RawToast]

On second look, the events are being passed through. I believe my bug is caused by the way only a single touch is handled. I believe reasongl behaves as follows:

• User touches and holds 'left' position (singleTouchId 1)
• Then presses and holds 'right'. As singleTouchId is set, the callback is not called and singleTouchId is reset to None.
• Then lets go of 'left' (touch id 1 changes, but as singleTouchId is none nothing happens)

[RawToast]

Another update: I am slowly adding multitouch support to reasongl on my fork my current plain is to:

• Accept multiple simultaneous touchIds, firing the mouse callback for each
• Replace ^singleTouchId to an array of existing touches

I can see this working well for touchstart, touchend, and touchCancel. The part I am most concerned with retaining the previous mouse position and making it touchId specifi -- for the initial cut that might not be touch specific.