Fractional x/y positions from touch events?

Solar2D General Questions/Discussion
#21

How is that possible?

The values in the list are printed in the “moved” phase which means that the device is obviously granular enough to detect the move. And if it can detect the move that has to mean that it knows that the coordinates of the touch point has changed, right? Also, how could the device even provide coordinates with that many decimals if it wasn’t able to detect/calculate them with more precision than that? I mean, it has to get those values from somewhere… It just doesn’t make sense.

If the values in my list above are what the operating system is passing on then it does not tell you all it knows about the coordinates. Then again, why would it only provide just a “few select values” when moving instead of all?

The test above was made on an iPhone 6 and I can reproduce it on an iPad as well. If that resolution is not granular enough, what is?

#22

I took your code and make a simple test case:

local touchObjectL = display.newRect( 100, 100, 100, 100 ) local function touchHandler( event ) print(event.x, event.y) if (event.phase == "began") then -- Store current position touchObjectL.markX = touchObjectL.x touchObjectL.markY = touchObjectL.y elseif (event.phase == "moved") then print(event.x) -- Set new position of touch object touchObjectL.x = (event.x - event.xStart + touchObjectL.markX) touchObjectL.y = (event.y - event.yStart + touchObjectL.markY) end return true end touchObjectL:addEventListener("touch", touchHandler)

And it produced this on my iPad 4 running iOS 10.1

Dec 03 10:33:57.304 [Device] 129.53125 135.9375

Dec 03 10:33:57.304 [Device] 129.53125

Dec 03 10:33:57.371 [Device] 129.296875 135.9375

Dec 03 10:33:57.371 [Device] 129.296875

Dec 03 10:33:57.404 [Device] 129.0625 135.9375

Dec 03 10:33:57.405 [Device] 129.0625

                    [Device] 128.828125 135.9375

                    [Device] 128.828125

Dec 03 10:33:57.440 [Device] 128.59375 135.9375

Dec 03 10:33:57.440 [Device] 128.59375

Dec 03 10:33:57.571 [Device] 128.359375 135.9375

Dec 03 10:33:57.571 [Device] 128.359375

Dec 03 10:33:57.600 [Device] 128.125 135.9375

Dec 03 10:33:57.600 [Device] 128.125

Dec 03 10:33:57.644 [Device] 127.890625 135.9375

Dec 03 10:33:57.644 [Device] 127.890625

Dec 03 10:33:57.673 [Device] 127.1875 135.703125

When I tried this on my iPhone 6, I got results that are strange, but for the purpose of this post the strangeness is a red herring. What is important is that I got incremental values unlike your tests where you show that the value basically blocks for a bit before the change, on the iPhone 6 and iPad 4 I was getting incremental values.

Can you try the code above? 

What is your config.lua like?

What version of iOS are you running on your phone?

Rob

#23

i think the easiest way to see this is to set a REALLY small content size (fe 40x60), then print not only the x,y’s from the event, but also an event counter - so that you can see on-screen how many times the same “quantized-to-content” integer values are returned (or adb logcat it looking for dup’d lines)

i can confirm that for build 2992 on Windows, and as built and running on an actual Android 5 device, that the attached code only returns quantized integer event coordinates.  (i’ve not tested if mac sim and/or ios device reproduce same)

a VERY SLOW drag across the width of device’s native 1080x1920 screen generates roughly 1000 events as expected, but only 40 unique integer event.x’s are ever reported, no fractional values whatsoever.

By increasing the content size to something more reasonable, you can get correspondingly LESS quantizing.  For app where touch/drag “precision” is required, 320x480 is nearly unusable. though 640x960 is often good enough.  By leaving out content size entirely config.lua, thus using device native pixel dimensions, completely eliminates the quantizing effect- though that defeats all of Corona’s self-scaling nicety features.

#24

@Rob: using your example, I can still get duplicate event.x values from consecutive “moved” phase printouts moving really slow but much fewer than in my original code. I will look into my code and see if I can find anything else that causes it. I use 2016.2995, iOS 10.1.1 and my config.lua is:

local aspectRatio = display.pixelHeight / display.pixelWidth application = { content = { width = aspectRatio \> 1.5 and 640 or math.floor(960 / aspectRatio), height = aspectRatio \< 1.5 and 960 or math.floor(640 \* aspectRatio), scale = "letterBox", fps = 60, imageSuffix = { ["@2x"] = 1.5 }, },

@davebollinger: as of 2016.2994 (see my post from yesterday above), event.x returns fractions. I ran your example in 2016.2995 and got more or less the same result as with Rob’s code. Your counter shows that consecutively triggered “moved” phases do produce duplicate values for event.x.

#25

that’s good news, a step in the right direction.

still, what you’d expect from a device of width “DW” would be DW unique values (fractional or not, depending on the ratio of content dimensions to device dimensions)

however, for content of width “CW”, there appears to be a flaw in the mapping from [0,DW) to [0,CW) because we’re only getting back CW unique values - that is, the range [0,DW) has been quantized to just CW unique values, somewhere apparently prior to being scaled by CW/DW.  perhaps some intermediate int value is used halfway through the calc that shouldn’t be? (wild guess)

#26

@davebollinger: good analysis! You are absolutely right, the number of  unique values returned should be DW. Above, Rob says that corona is basically just relaying the values that the os gives. If so, it could be that the quantizing occurs outside of the reach of corona unless there is a way to modify the behavior of the os in this regard, I don’t know…

@Rob: could you please double check that corona does absolutely nothing with the values passed form the os? If so, could the “device based” coordinate values be extrated from the os in another way?

#27

We scale the values based on your config.lua settings. If you define 320x480 an you’re on a 640x960 device, we will have to halve the values to map them to your 320x480 content area.

Rob

#28

@Rob: as you can see in my config.lua (see previous posting) I now use a 640 x 960 resolution. Given the imageSuffix settings (see same posting), iPhone 6 does not need scaling. Therefore, content scaling cannot be the reason for this issue. More importantly, it does not explain the results that davebollinger points out in his postings  about quantization.

#29

At this point since you have a reproducible test case, please file a bug report using Dave’s project.

Thanks

Rob

#30

suggest you first try your own code against latest daily build, cuz it appears that…

from dawn of time to build 2992, problem existed cuz only integral coordinates reported

some time prior to 2994, fractional coordinates were added (but still quantized to content dimensions)

some time prior to 2999, fractional coordinates do NOT appear to be quantized any more

  (that is, all possible fractional values appear to be being reported)

attached is what i was going to submit as a bug report myself, but am no longer planning to do so as I no longer see the problem myself.  if you still see the problem, feel free to use/reuse it if it helps in any way as a bug submission of your own.

#31

I would suggest still filing it Divergent Monkey if you’re still seeing the issue with 2999 and Dave’s sample.

Running his previous sample with 2997 and now 2999 I still get two or three repeating values in the simulator. 

Rob

#32

I have already filed a bug report, that’s why we went from integers to at least some fractional values. If you look at my posting from December 2, you see the answer I got from Corona support about a month after filing. The issue then became that fractional values were quantized but according to davebollinger it seems to be resolved now. I’ll download 2999 and see if the problem exists (or at least still has a significant effect). If so, I will file another bug report.

#33

Nope.  Same answer, sorry.

You need to use a higher resolution setting in your config.lua file.

#34

But that would mean that the whole content scaling stuff is kind of flawed since it automatically also means that objects cannot be dragged smoothly. In an older thread I found a developper who set the size to 1600 x 2560 and simply downscaled from there, only to get rid of the “jagged dragging”. The response from the Corona staff was that it might cause memory problems since devices with a lower resolution tended to have less memory. Also, the whole reasoning behind the “ultimate config.lua” discussion falls if a consequence of it is this. Third, in my case, the game is finished and I have a lot of images. Changing the resolution would mean recreating all those images, which would be a very time consuming task…

Wouldn’t all this be solved if the listener (which obviously is triggered by fractional moves) also allowed for fractional event.x values?

At Corona staff: is this something that you have considered adding as a feature?

#35

You should be getting fractional content locations and your dragging should be smooth unless you’re setting things to whole numbers.

Rob

#36

But the event.x property of the touch event only returns integers…

I tried a very simple example following the tutorial (https://coronalabs.com/blog/2011/09/24/tutorial-how-to-drag-objects/) while printing the value of event.x to the xcode console from an iPad. All I get are integers. Or is there another way of getting content location that can be used when dragging?

#37

I made a demo reproducing your findings and I’m surprised.  Once Rob mentioned it I was sure we used to get fractional values.

However, I’m not seeing them either.

This demo can easily be tested at any multiple of 320 x 480 by adjusting the variable ‘scale’ in config.lua on line 9.

https://github.com/roaminggamer/RG_FreeStuff/raw/master/AskEd/2016/10/fractional_touch.zip

‘scale’ is actually an inverse-scale, so 0.5 means 640 x 960 while 2 means 160 x 240.

By changing this one line, the rest of the demo will adjust.  I tested these scales :

  • 0.5 - 640 x 960 
  • 1 - 320 x 480
  • 4 160 x 240
  • 8 - 60 x 40 - Noticeable stepping**  during drag.**
  • 16 -  Super Noticeable stepping during drag.

https://www.youtube.com/watch?v=tmoyS_Jdu0w&feature=youtu.be

#38

If you’re going to file a bug or feature request, feel free to snag the demo and use it.  I think it clearly shows the issue your describing and is easy to use as a test for a fix/change.

PS - I didn’t print them to the screen (and should have), but the event <x,y> values are coming through as whole values.

#39

At RoamingGamer: yes, that is exactly what I mean, thanks! Given Rob’s posting, I have submitted a bug report with your sample code.

At Rob: any chance we have misunderstood what you meant? Did you perhaps not mean then event.x property?

#40

First of all, we’ve not made any changes that would affect the x and y returning from events. There is a distinct likelyhood that I’ve not paid attention to the values in a while and I could be wrong. 

So it’s not likely a bug other than me getting confused. You can position items with fractional x, y’s. Transitions and physics use fractional x, y’s. But I guess it’s possible that the event.x, y of a touch is coming in with whole content unit values.

Rob