search

prime31 / TouchKit

Gestures and input handling made sane for Unity
906 stars 137 forks source link

Feature/distance in centimeters #23

Closed newcommat closed 9 years ago

newcommat commented 9 years ago

Main motivation was to be able to express distance of touch input by centimeters rather than abstract pixel value against a reference design resolution.

So for example constructing TKSwipeRecogniser(2f, 1.5f) describes a swipe with a distance of 2cm and variance of 1.5cm

This is achieved by using Unity's Screen.DPI value as a method on TouchKit instance. Note this is supported for almost all devices, we use a fallback of 72 dpi if not (e.g. Editor).

Finally the code is upgraded to reflect Unity 5

prime31 commented 9 years ago

Looks good. My only worry would be all the Android phones that Unuty doesn't report a dpi for. I haven't tested for a while so hopefully dpi ha better coverage now.

newcommat commented 9 years ago

I agree with that concern in general. A fall back of 72f seemed sensible when I wrote it but maybe based on this:

A set of six generalized densities: ldpi (low) ~120dpi mdpi (medium) ~160dpi hdpi (high) ~240dpi xhdpi (extra-high) ~320dpi xxhdpi (extra-extra-high) ~480dpi xxxhdpi (extra-extra-extra-high) ~640dpi The generalized sizes and densities are arranged aro

We should go for android medium (160) as the fallback. I've tested with a number of devices locally and all have reported their DPI correctly. I'll try and get some older low end to double check. Certainly open to suggestions for better fall backs but it's worth mentioning that the issue goes both ways, if we stick to resolution then the distance the user needs to move their finger changes dramatically for DPI

At least here we are compensating for DPI, then distance will change only on devices where it's not fully supported

newcommat commented 9 years ago

http://developer.android.com/guide/practices/screens_support.html

prime31 commented 9 years ago

I think having a fallback of 160 on Android and 72 when on desktop would probably cover most cases. I checked with another Android dev and supposedly Unity fixed up Screen.dpi so it may be that the "0" responses won't even be present on the platform anymore.

Mike

On Apr 28, 2015, at 9:23 AM, newcommat notifications@github.com wrote:

I agree with that concern in general. A fall back of 72f seemed sensible when I wrote it but maybe based on this:

A set of six generalized densities: ldpi (low) ~120dpi mdpi (medium) ~160dpi hdpi (high) ~240dpi xhdpi (extra-high) ~320dpi xxhdpi (extra-extra-high) ~480dpi xxxhdpi (extra-extra-extra-high) ~640dpi The generalized sizes and densities are arranged aro

We should go for android medium (160) as the fallback. I've tested with a number of devices locally and all have reported their DPI correctly. I'll try and get some older low end to double check. Certainly open to suggestions for better fall backs but it's worth mentioning that the issue goes both ways, if we stick to resolution then the distance the user needs to move their finger changes dramatically for DPI

At least here we are compensating for DPI, then distance will change only on devices where it's not fully supported

— Reply to this email directly or view it on GitHub.