Regression bug starting in .685 on xStart / x multitouch values

Solar2D Daily Builds and Public Releases
#1

Hi -

My button /swipe handlers stopped working correctly in .685.
I’m using dynamic scaling (320x480/letterbox).

A touch “ended” event that doesn’t involve any movement at all now returns an xStart and an x value that are completely different. The difference increases the further away you are from the left edge of the screen.

I see this in the release notes for .685:
casenum 9618: Fix for xStart and yStart for multitouch moved/ended events when using dynamic scaling.

So, I think this is a regression bug. I’ll put together some quick test code and file a bugreport.

Scott
[import]uid: 31041 topic_id: 18014 reply_id: 318014[/import]

#2

Hey Scott, if you wouldn’t mind posting the bug report # here that would be helpful.

Thanks,
Peach :slight_smile: [import]uid: 52491 topic_id: 18014 reply_id: 68878[/import]

#3

After spending some time trying to recreate the problem in test code to upload witha bug report, I think I’ve isolated the problem, and I’m not sure it would be considered a bug. It’s definitely a change in behaviour that starts in .685, but it’s easily worked around.

The mitigating issue is that my buttons animate by scaling down when touched, and scaling back up to 100% when released. The changes in .685 must rearrange the timing of capturing the gesture start or end position relative to my scaling events. Specifically, it seems to be capturing the xStart/yStart positions now after my ontouch scale transform, and applying the transformed scale to these values. Prior to .685 it was either not capturing the positions before the transform, or it was not factoring the transformed scale into the position.

I can easily work around this by recording my own xStart/yStart position on the “began” event before applying the transform, or by setting the event on a group that contains the scaled object, but isn’t scaled itself.

In any case, as far as I am concerned, we can consider this resolved.

Scott

[import]uid: 31041 topic_id: 18014 reply_id: 68946[/import]

#4

Ugh; there’s more going on here than I thought. There definitely is a bug, but I just can’t isolate it.

In my app, in the iPhone 4 simulator, event.xStart is off by a factor of 0.5 from event.x.
In the iPhone simulator, they match.
On the droid simulator, it’s off by .66

In all of these cases, the ratio it’s off by is = display.contentScaleX.
if I divide the reported event.xStart value by display.contentScaleX, I get the correct result (matches event.x)

However, in the iPad simulator, event.xStart is off by a factor of .36, but display.contentScaleX is .46

What’s frustrating so far is that I can’t replicate this event.xStart ~= event.x in a simple test app to upload with a bug report. There’s something else about my app that is triggering this bug to surface.

Again, this started in .685, where there was some fix for something related to .xStart and content scaling.

Should I file a bug report with this information? It’s inconclusive, but it definitely started in .685.

Scott
[import]uid: 31041 topic_id: 18014 reply_id: 69027[/import]

#5

I was able to get the error to reproduce in a fairly small sample app which I uploaded as bug case 9813.
[import]uid: 31041 topic_id: 18014 reply_id: 69028[/import]

#6

There was a behavior change due to the bug fix. xStart and yStart were returning non-content scaled values on moved/ended phases. They should have been the same content scaled values seen in the begin phase.
[import]uid: 7563 topic_id: 18014 reply_id: 69032[/import]

#7

There’s still some kind of inconsistency going on - the sample code I uploaded with the bug illustrates. I’m getting incorrect values for an .xStart on moved/ended event. Incorrect meaning does not match .x in a non-moving touch and release.
Thanks,
Scott [import]uid: 31041 topic_id: 18014 reply_id: 69055[/import]

#8

Calling system.activate( “multitouch” ) fixed this.
Apparently how I was using it it worked before without doing this.
No problem-thanks

[import]uid: 31041 topic_id: 18014 reply_id: 69217[/import]