I'm making a simple kiosk app which involves moving some balls around the screen. I'm using GestureWorks 4.1 and FDT. The balls are simple on the stage, not inside any other clip and they, themselves are the TouchSprites.
A strange bug has occurred which seems to only be in Air App version (although possible there is a tiny hint of misalignment over time dragging on the development version too).
As you drag an item its the new x/y coordinates being mapped to are scaled up. I only have to drag around 1/3rd of the screen relative to the first touch point to make the object itself go around the perimeter of the full screen. I can't see anything to account for this at all and just hoping someone has an idea of how this could suddenly happen? I'm sorry that time is such a pressure I'm unable to show an isolated example. But the gml is simple and standard and works properly when testing locally, just not when part of an Air app tested on the same machine.
My development testing is full screen as is my Air App.
I have tried both the standard n-drag and the n-drag_inertia gestures, I have tried turning native transform off and updating the location on the drag event too and the result is the same.
Like I mentioned, time is a bit of a pressure, this was to be a final build being deployed today! Yikes!
If anyone has any suggestions as to what this could be I would be delighted to hear them!
The 'n-drag' gesture can be activated by any number of touch points between 1 and 10. When a touch down is recognized on a touch object the position
of the touch point is tracked. This change in the position of the touch point is mapped directly to the position of the touch object.
Sorry, last paragraph was a comment stripped out the gml I pasted in. Ignore last paragraph!
I'm still battling away with this bug and I now have a completely stripped back version with nothing else at all in the file and its still happening. If anyone is interested I can send the project over. FDT is my compiler of choice and I do realise that you don't officially support it. I've tried downloading Flash Develop to set the project up in there but its pretty unfamiliar territory for me. I will continue on my quest!
So, I found a fix in the end, which I will post in case it helps anyone else.
The default size was set in FDT and did not match the size which I was setting in the root .as file like so "[SWF(width = "1920", height = "1080", backgroundColor = "0xECEFF2", frameRate = "30")]"
Gestureworks must configure using the default property size of the project at different times depending on whether its playing on local air player or the compiled player... or something along those lines!
To fix the default size in an FDT project, right click on your project > Project Properties > FDT Compiler > Compiler Arguments > "default-size"
I'm basically talking to myself here but this has been such a frustrating issue that if I can help someone else I will!
The screen size was a bit of a red herring, or only fixed part of the problem. The following reduced its occurrence dramatically.
Setting the frame rate to 30
Using Air Player 3.5 instead of the latest 4.1
Changing the filters on the standard drag gestures from the defaults. Friction reduced to 0.8, and delta min and max 0.0001 - 50.
The issue is still not perfect but as close as I've been able to get! Seems to me like there is an issue where if the frame rate drops, seems like gestureworks is updating at an independent rate and this means x/y properties of objects being updated more frequently than they should be and so appear to travel farther than they should.
I had a similar problem some time ago, and setting the frame rate to 30 seems to have fixed the problem for me. See this thread - http://openexhibits.org/community/groups/oe-software-support/forum/topic/touch-screen-resolution-mismatch/.
The 30 Frame rate worked for me too.
Another thing to remember is try not to actually move the touch sprite itself
rather put it inside the movie clip and move the movie clip around instead
helped me when i was changing resolutions