Right Mouse Button Hack about touchscript

[valyard]

Why do you need right mouse button?

Because our designers specified it for devices that are controlled by mouse and i did not want to have two separate handlers for mouse and touch inputs.

[valyard]

So you want right click to behave exactly like left click — generate a touch? What happens if I press both buttons?

Exactly. If one Mouse button was pressed the other one is blocked. If both are hit simultaneously, the left mouse button is preferred. The game script additionaly supports this behaviour. I don't think this is the best solution in general, but the hack supports our design.

[ChuckWalters]

Even though Touch remains the focus of TouchScript, a unified solution would be nice. For complete mouse support, all buttons and the wheel should be supported. It would also be nice to add Joystick and Keyboard support to the mix. The Unity "InputManager" provides the configurable interface to define a single action on Mouse, Keyboard, and Joystick. I'm coding a new InputSource for this called "UnityInput.cs". It contains logic similar to that in MouseInput and MobileInput but uses the Unity InputManager (from Unity editor menu, see: Edit->ProjectSettings->Input).

Examples:

TouchScript method

Input.GetMouseButtonUp(0);

Unity InputManager method

   public string ButtonName= "Fire1"; // Name of the first button
   float buttonState = Input.GetAxis( ButtonName );
   if( buttonState == 1.0f)
   {
      //Button down logic 
   }else
   {
      //Button up logic
   }
   public string AxisName = "Mouse ScrollWheel"; // Name of the zoom or scroll axis
  
   float zoomOrScroll = Input.GetAxis( AxisName );
  
   if(zoomOrScroll < 0.0f)
   {
      // ZoomOut or Scroll Down logic
   }
   else if(zoomOrScroll > 0.0f)
   {
      // ZoomIn or Scroll Up logic
   } 

Buttons are on/off, while Axis are ranged neg,0, or pos, which requires two separate processing schemes as outlined above. To process all user desired Buttons and Axis, provide a user list for each ButtonNames and AxisNames (with the basic inputs set as defaults). User can replace defaults or add to each list with additional buttons and axis.
"MousePointId" should be designed to account for which button or axis was processed.

This approach should process most non-touch gesture input sources.

[valyard]

TouchScript is for handling multi-touch gestures. It does this job well. There's no point to make an universal framework. It should support everything which translates to touch like mouse (mainly for debug purpose and single-touch screens), tuio and native touch events. Everything else doesn't fit here.

[ChuckWalters]

Realizing the scope, though your touch gesture solution comes so close to a universal input gesture solution. Felt the need to point out just how close.

Thought about using TouchScript in conjunction with a separate game input system but leaning towards using TouchScript exclusively with a few mods.

1.   Create small pools for event objects to avoid gc hit.
   

2.   Create UnityInputSource: Using the Unity InputManager to effectively support mouse, joystick/pad, and keyboard.
   

3.   Create 2DCameraLayer:  To add Collider2D support.
   

4.   Add “Hover” recognition as a gesture.
   

The TouchScript’s modular architecture makes it enjoyable to work with.
Thanks for open sourcing it.

[valyard]

Thanks for the feedback.
The library is open source so everyone can fork it, make changes and convince me that these changes are good (8

Create small pools for event objects to avoid gc hit.

All the events are standard C# events with standard event args. A lot of them are created every second, you are right. Never though if I need to do anything with it. But I know people use their own event solutions on mobiles.

Create UnityInputSource: Using the Unity InputManager to effectively support mouse, joystick/pad, and keyboard.

As I said, everything must convert into touch points. How do you think I should map joystick and keyboard to touch points? o.O

Create 2DCameraLayer: To add Collider2D support.

Working on it. Almost ready.

Add “Hover” recognition as a gesture.

Unfortunately there's no hover state in touch interfaces o.O

[ChuckWalters]

Mapping Joystick and Keyboard:
· Use these to simulate single touch. Assume a Cursor always on screen. Then Joystick, Mouse, keyboard Arrows make sense as single finger touch.
o Simulating a cursor with touch always down, the accelerometer could also be added as an input. This makes a case for using a Hover state.
· TouchScripts “Scale” gesture can easily be hooked to any of these axis. Mapping to two fingers getting closer or moving apart aka “pinch zoom”.
· Rotate also possible with special assigned axis and that can simply work on a normalized mapping of one finger at absolute zero and static, with other finger rotating with axis.
· Button support on all these can be used as Tap Gesture input with specialized ID. Possible simulations to touch:
o Buttons map to an Nth-Finger multi-touch tap e.g., 2 fingers down and a third finger taps.
o Buttons map to a N-Finger tap. 2+ finger simultaneous tap where locations may be unimportant, just the fact there were N fingers and they all tapped simultaneously.

Collider2d
I’ve seen several solutions to the Collider2D hittest. The simplest being:

Vector3 screenPoint = Input.mousePosition;
Vector3 worldPos = ActiveCamera.ScreenToWorldPoint(screenPos);
Collider2D[] HitCollider = new Collider2D[1]; // Set to number of supported collisions, 1 returning only the closest collision to camera
int numHits = Physics2D.OverlapPointNonAlloc(worldPos, HitCollider);

Hover:
· When a single finger is down, it is also over some object. With TouchScript’s “Friendly Gestures” one could have a “Hover” and/or “Down” gesture firing.

[valyard]

Unfortunately keyboard/mouse/joystick mapping and hover can't be easily integrated in current design and they simply don't fit there. Hooking stuff to gestures completely breaks the design. You shouldn't be able to manually control gestures, gestures are state machines which only job is to recognize patterns in touch input. It implies that there is touch input.

The most important event in TouchScript is when a touch input occurs. At this stage one or more gestures may "take" this touch point and work with it. If a touch point appears not within a gesture boundary this gesture can never have this touch.

This is why there can't be hover behavior.
Of course it could be done but it would involve some mechanism to share touch points between gestures after begin stage. And first, I haven't thought the right way to do this, second, this functionality is almost never needed and can be simulated.

What you described is not TouchScript, it's something else. Totally different library/framework.

P.S. yes, I'm using Physics2D.OverlapPointNonAlloc to check if a touch hits a 2d collider.