The blog post http://android-developers.blogspot.com/2010/06/making-sense-of-multitouch.html was a good read but oddly enough it doesn't really cover multi-touch IMHO. It covers tracking a single touch where another touch could follow. My game needs to track one touch for the game pad and then at least another for the fire buttons.

Currently my game is broken on the Xoom and I'm assuming it's because of the same problem this thread talks about. I can make the changes as others have suggested by mapping but I still have some issues. I'm not sure if I handle Cancel correctly. It's a really large concern as my game captures pointers so I know whether the finger was over the button it pressed when it was released. I really need to get matching events or buttons will get stuck. It's not so bad when IDs are 0 or 1 but when they cycle to 15 it will be harsh.

As you can see I have added some sleep code below but I'm not sure if it's needed. It's really hard to know what to do here as people complain about unresponsive controls but they work fine on my phone and I just don;t have the funds to be buy 3-4 other phones.

Here is my code I use to inject pointer events into my game engine.

    @Override

    public boolean onTouch( View v, MotionEvent event )

    {

        int             action         = event.getAction();

        int             numPointers    = event.getPointerCount();

        int             ptrIndex    = (numPointers>  1) ? (action&  
MotionEvent.ACTION_POINTER_ID_MASK)>>  MotionEvent.ACTION_POINTER_ID_SHIFT : 0;

        int             ptrId         = event.getPointerId( ptrIndex );

        PointerEvent    pe            = null;

        switch( action&  MotionEvent.ACTION_MASK )

        {

            case MotionEvent.ACTION_DOWN:

            case MotionEvent.ACTION_POINTER_DOWN:

                pe = (PointerEvent)m_PointerEvents.alloc();

                if ( pe != null )

                {

                    pe.owner    = m_PointerEvents;

                    pe.action    = PointerEvent.ACTION_DOWN;

                    pe.id        = ptrId;

                    pe.x        = (int)event.getX( ptrIndex );

                    pe.y        = (int)event.getY( ptrIndex );

                    m_App.getGame().postUIEvent( pe );

                    //m_App.getLogger().verbose( pe.toString() );

                }

                break;

            case MotionEvent.ACTION_UP:

            case MotionEvent.ACTION_POINTER_UP:

            case MotionEvent.ACTION_CANCEL:

                pe = (PointerEvent)m_PointerEvents.alloc();

                if ( pe != null )

                {

                    pe.owner    = m_PointerEvents;

                    pe.action    = PointerEvent.ACTION_UP;

                    pe.id        = ptrId;

                    pe.x        = (int)event.getX( ptrIndex );

                    pe.y        = (int)event.getY( ptrIndex );

                    m_App.getGame().postUIEvent( pe );

                    //Log.v( "POINTER", te.toString() );

                }

                break;

            case MotionEvent.ACTION_MOVE:

                {

                    // There are reports that move touch evens can flood the 
system.  The suggested

                    // solution is to sleep after a move.  I don't want to 
sleep unless I have to

                    // since it could cause controls to be unresponsive.  So 
instead I will only sleep

                    // if we get more than one move event within a 60Hrz frame 
and then I will only

                    // sleep as much as I need.  It's very much along the lines 
of a update loop.

                    long    currentTime = System.currentTimeMillis();

                    long    elapsed        = currentTime - m_LastMoveEventTime;

                    if ( elapsed<  16L )

                    {

                        try

                        {

                            Thread.sleep( Math.max( 0, 16L - elapsed ) );

                        }

                        catch( InterruptedException e )

                        {

                            Thread.currentThread().interrupt();

                        }

                        break;

                    }

                    for( int index = 0; index<  numPointers; ++index )

                    {

                        ptrId = event.getPointerId( index );

                        if ( ptrId>= 0 )

                        {

                            pe = (PointerEvent)m_PointerEvents.alloc();

                            if ( pe != null )

                            {

                                pe.owner     = m_PointerEvents;

                                pe.action    = PointerEvent.ACTION_DRAG;

                                pe.id        = ptrId;

                                pe.x        = (int)event.getX( index );

                                pe.y        = (int)event.getY( index );

                                m_App.getGame().postUIEvent( pe );

                                //Log.v( "POINTER", te.toString() );

                            }

                        }

                    }

                    m_LastMoveEventTime = currentTime;

                }

                break;

        }

        return true;

    }

Leigh

On 5/17/2011 2:01 AM, Jeffrey Brown wrote:
Pointer IDs are arbitrary integers.  The only guarantee is that they
will be unique for a given finger as long as that finger remains down.
  Once the finger goes up, the id may be reused for a different finger,
or it may not.  It really depends.

The problem with spurious ACTION_DOWN events is strictly a software
issue, not hardware.  It happens when applications filter or modify
the stream of touch events in a manner that causes them to become
incomplete or inconsistent.  The bugs can be quite subtle.

Jeff.

On Mon, May 16, 2011 at 3:56 PM, MichaelEGR<[email protected]>  wrote:
ugh!  Thanks for posting this message as this is a gnarly one and an
example of ODM fragmentation if pointed IDs are not indexing correctly
to the proper point data at least. I never was impressed by the
multitouch API and always thought it wasn't thought out well and
simply just tacked onto MotionEvent. Dirty as you say it is correct. I
also wasn't pleased with the lack of documentation and unclear
contract. Perhaps this lack of documentation led to this potential ODM
fault. As for spurious ACTION_DOWN events this could be from varied
quality of touchscreen hardware too.

So from my reading of your post you are saying that pointer IDs are
not recycled and that the data of subsequent pointer IDs is not
correct at the specified array index?

Not looking forward to coming up with a solution for my platform /
middleware / custom event system and certainly am not excited if I
need to buy an Experia Play just for this, but w/ talking with Robert
G. it sounds like button support on this device is a bit wacky too. If
I understand correctly button presses don't generate key events? Hrm;
I hope that is not the case as I hate to have to waste $500+ to fix
these kinds of issues. Likely I'll pick one up, fix the issues, then
sell it.

Regards,
--Mike

On May 16, 12:58 pm, Mario Zechner<[email protected]>  wrote:
A user reported an ArrayIndexOutOfBoundsException today in our multi-
touch handler. We store x/y/touchState on a per pointer id basis in an
array. Dirty? Yes, but it worked on all devices so far. Usually
pointer ids are handed out like this:
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


--
Leigh McRae
http://www.lonedwarfgames.com/

--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to