Circle and Ellipse shapes don't throw Touch Events

[themick88]

Shapes drawn with drawCircle and drawEllipse will not properly dispatch the TouchEvent.TOUCH .

All other shapes drawn (e.g., with drawRect, drawRoundRectComplex) will properly dispatch TouchEvent.TOUCH . Even if drawCircle is added to the same graphics object, it will not dispatch the event.

[themick88]

        private function onAdded ( e:Event ):void
        {
            var shape:Shape = new Shape();
            addChild(shape);
            shape.x = 20;
            shape.y = 20;

            // Rect drawn with drawRect()
                        // WILL detect touch here
            shape.graphics.beginFill(0x8dc63f);
            shape.graphics.drawRect(0, 0, 100, 100);
            shape.graphics.endFill();

            // Filled Circle
                        // WILL NOT detect touch here
            shape.graphics.beginFill(0xfcc738);
            shape.graphics.drawCircle(380, 50, 50);
            shape.graphics.endFill();

            shape.addEventListener(TouchEvent.TOUCH, touchThis);
        }

        private function touchThis(event:TouchEvent):void
        {
            trace("event ", event.data);
        }

[IonSwitz]

First off, thanks for a great reproduction example. Makes my "job" a lot easier. :)

However, this is odd.

This works perfectly for me. The trace output looks like this, for example:

event Touch 0: globalX=123, globalY=93, phase=hover event Touch 0: globalX=114, globalY=87, phase=hover event Touch 0: globalX=120, globalY=88, phase=hover event Touch 0: globalX=361, globalY=105, phase=hover event Touch 0: globalX=370, globalY=104, phase=hover event Touch 0: globalX=371, globalY=104, phase=hover

The first three are from the square to the left, and the second three come from the circle. I run this on a regular PC, not a mobile phone or similar.

What platform are you using? Mobile? Are you using the SWC or the code tree? (there is a slight difference in content, I believe)

EDIT: Also, about a week ago, I submitted a fix for the bounding box of Circle (and Ellipse) was being miscalculated. Maybe that's the problem? If you update the source tree, and build off it, you should be ok.

[themick88]

@IonSwitz - thanks for the reply. I'm using Starling v.1.3 (15 Jan 2013) and Graphics Extension from 5 Nov 2013. Perhaps that combo is what's causing the issue. Thank you for confirming that everything works in the most recent version(s). For what it's worth, I am testing a desktop app.

I updated the Graphic Extension framework to the current version (25 Nov 2013) and I still have the same issue. In both cases I was using the SWC. Perhaps it's tied to the version of Starling that I'm using. I'm not lead on the project I'm working on, so I can't update Starling, but I'll put in a request to the project lead.

Feel free to close this issue since it's apparently something on my side and not with the Graphics Extension. Thanks again!

[jonathanrpace]

Try compiling against the code, rather than the SWC. It's not been kept up to date lately ( I used to use Flashbuilder, which made doing this a cinch - but have since switched to Flashdevelop. I'll be setting up an ANT task to make this easier in future ).

[IonSwitz]

Since the Circle, Ellipse, and hence the NGon showed up, I decided to add precisionHitTest support to the NGon class.

This is done in two ways: For fully filled, fully circular circles (and elipses), the test is a simple hitpoint vs radius test For more complex NGons, I am comparing against the triangles making up the shape, if the hit point is within the boundingBox of the NGon, using the isPointInTriangle code from the Fill class.

Also, I fixed an issue where the new uvMatrix code crashed when the uvMatrix wasn't set. Just added "if ( uvMatrix )" before the transformation call, to make sure we don't crash on simple NGon cases, as the one in the PrimitivesExample:

var nGonA:NGon = new NGon(50, 10); nGonA.x = 200; nGonA.y = 60; nGonA.material.color = 0x0066CC; addChild(nGonA);

Also, I changed the winding of the indices for the triangles in a few cases in the NGon. I wanted to be able to use the same "isPointInTriangle" math as used in the Fill class, and the winding had to be adjusted for the triangles in the Arc and Hoop case. It shouldnt have any other impact, right?

[IonSwitz]

Also added a refactoring of isPointInTriangle and isLeft. Since they are used in two classes now ( and probably in TriangleStrip and TriangleFan further down the road) , I moved it to a TriangleUtil class.