multitouch status

edited May 2013 in Help request
I realize that currently there is no built-in support (ie orx types) for dealing with multitouch. Hence, I will start rolling my own solution for this. However, I want to keep this development close to whatever the eventual orx solution will be, so that I can merge to the official branch without too much difficulty. Any do's/dont's/advice before I begin?


  • edited May 2013
    some choices:

    - Implement GestureDetector in java and create a new orx event type for this.

    - Keep everything client-side, and have the game keep track of pointer/finger activation. In this case, it would be nice to also receive pressure and timestamp info with each touch event. The timestamp would be used in client-side gesture detection. Alternatively time could be saved at the point of event arrival in client code, but this has obvious drawbacks.
  • edited May 2013
    There's no query API however all the touch (including multi-touch), motion and accelerometer events are uniformized as orxSYSTEM events.
    typedef enum __orxSYSTEM_EVENT_t
      orxSYSTEM_EVENT_CLOSE = 0,
    } orxSYSTEM_EVENT;
    typedef struct __orxSYSTEM_EVENT_PAYLOAD_t
        orxU32      u32FrameCounter;
        /* Touch event */
          orxDOUBLE dTime;
          orxU32    u32ID;
          orxFLOAT  fX, fY, fPressure;
        } stTouch;
        /* Accelerometer event */
          orxDOUBLE dTime;
          orxVECTOR vAcceleration;
        } stAccelerometer;

    That being said, I don't know the details about the Android implementation of those.
  • edited May 2013
    I just added the pinch zoom by way of Java-side ScaleGestureDetector. This also involved adding 3 new events to orxSYSTEM_EVENT.

    - ScaleBegin
    - ScaleChanged
    - ScaleEnd

    The user will then catch these in their SystemEventHandler. Payload that comes with each of these is:

    - X,Y of center of gesture
    - % change from last scale (instead of pressure)

    The code is up in my orx fork
  • edited May 2013
    Sounds good, however I think I'd name them differently, after the gesture's name instead of the potential use of it.

    Also I think we could regroup all gestures under orxSYSTEM_EVENT_GESTURE_BEGIN, _GESTURE_MOVE and _GESTURE_END, using then an enum of type orxSYSTEM_GESTURE_TYPE to get the relevant data within the payload.
  • edited May 2013
    Feel free to rename as you see fit ;)

    Yeah, they could certainly be regrouped, I was going for minimal changes at this point (like highjacking of pressure value for scale storage).

    One thing I realize that I did wrong is with the negative numbered enums, as that would mislead EVENT_TOTAL (luckily it is not currently used anywhere). We do need them to stay fixed somehow, as the values are copied in java.
  • edited May 2013
    Sure, I can try to integrate it either this week end or sometime next week, however I'll put it first in a staging area as I can't test on Android and would like to minimize the chances of me breaking anything. :)
  • edited May 2013
    +1 for gesture events, swipe events would be nice too.

    I think the best would be to let iarwain do the iOS implementation (when he has the time).

    That way, all the orx events enums, structs and stuff will be there, and ready to be reused for Android.

    As I said in your commit, If you are going to contribute to orx Android port, the best would be to fork my repository as iarwain is unable to test Android yet, so I can review and adapt your changes.

    It reduce also the risk of conflict when merging from orx upstream.
  • edited May 2013
    hi lydesik, ok, I will redo the scale gestures as you suggested - with a new pipe and a new set of events. I will add the swipe gestures as well, it will fit right in.

    About orx forks, is there any way to do inverse pull requests? Reason being, is that I already have two copies of orx going - the official and my temp staging area. So it would be really great if there was a way for me to send you my code without making yet another copy of the project. Any suggestions?
  • edited May 2013
    Pull requests non-standing, one local repo should be enough. From that repo you should be able to pull from any source, whether it is orx's main repo, lydesik's one or yours on bitbucket. That's the advantage of DVCS.

    Now for the actual pull request feature of bitbucket, I think an easy way to do it would be to remove your current fork (but keep your local clone), fork lydesik's one on bitbucket and set that fork as your default remote repository on your local one.

    You can either do that by using a GUI client such as TortoiseHg or by editing the .hg/hgrc file of your local clone. Of course if you use the exact same name as your previous fork (ie. the remote addresse doesn't change), you won't even need to do that editing step, it should work right away with your local clone.
  • edited May 2013
    I got the gesture stuff put in. The changes are in my fork of loki's orx (zokzok/lokiOrx).

    The only thing that I'm still not settled on is the contents of the gesture events. Android's gestures are not a uniform bunch, and callbacks have different parameters. For now, there are two floats for holding whatever comes with the event. Additionally, some gestures don't have a begin and end (such as fling) so it just comes through under gesture_changed.
Sign In or Register to comment.