koobas.hobune.stream
Android Touch Variation Correction? (How to use Screen.dpi?)
This has been some confusion as to what I am asking on both sides (As I wasn't clear or completely sure myself). I'm having a problem formulating the word problem (Not solving it) of how this:
can help me normalize this:
So that I can have a one, scaling solution across multiple resolutions (and platforms) like these:
For instance, I suppose I could use PPI (Pixels Per Inch often known as Dots per inch - DPI) to calculate the physical size of the screen and download an appropriate resolution set of UI(assume we have a server with many resolution sets of User Interface available for download) specific to that size (Again, how does PPI even relate the resolution to physical screen size?)
This current problem is where does PPI (Screen.dpi) fit into calculating a normalized swipe delta change across multiple size screens?
Please let me know if I can be any more clear, because "divide/multiply as necessarily" is not helping me determine the relationship between PPI and normalizing swipe distance.
Note: these images were pulled from random google searches of:
pixels per inch
swipe
android screen sizes
Original:
So building off of my first question, Delta Position is different for every Android phone type. Is there a good way to go about correcting it between phones with an algorithm? Our director doesn't want to put something inside the game to change the sensitivity because most of our target audience (teachers) wouldn't even bother this.
Edit:
Ok, so I guess its time to revamp the question. Jessy pointed out that Screen.dpi would help with the correction, but how would .dpi be used in an algorithm to scale uniformly across multiple dpi's? I don't even know where to begin with constructing a formula to achieve this.
Here is the quick code I threw together to get an effect:
Vector2 = Input.touches[0].deltaPosition;
float speed = ms.y / Screen.dpi * 10;
Why am I dividing the vertical delta position? I have no idea. So what would be a correct way to use Screen.dpi so that it would scale across android devices(and ideally to ios devices as well)?
It would help if you answered my comment from two months ago, but I'm not sure we can help you. Are you familiar with ratios/division/multiplication? You'll need to be.
I'm not familiar with how to use Screen.dpi. What would be a practical use? It returns a float that has the number of pixels per screen (right?) So what do I do with that? $$anonymous$$ultiply it against the target screen resolution? I know that its useful, but I simply don't understand how to use that information.
Not right. Other Screen and Camera variables yield resolution information. dpi is a misnomer, but close enough - it should be ppi. That is, Pixels Per Inch. For your calculations, that mean you have (Screen.dpi pixels)/(1 inch). $$anonymous$$ultiply and divide as necessary to achieve your goals.
DPI is irrelevant. The key is Touch.deltaTime.
The Touch.deltaPosition is the change in position over that time, not over the time of the last frame (the Unity docs are slightly unclear on this, since the events themselves arrived during the last frame). This is why the sum of all Touch.deltaPosition values will not equal the difference between Touch.position values.
You can account for this as follows:
t.deltaPosition * Time.deltaTime / t.deltaTime
So, the code for dragging a scrollview would be:
position = GUILayout.BeginScrollView(position);
...
GUILayout.EndScrollView();
if (Event.current.type == EventType.Repaint) {
var area = GUILayoutUtility.GetLastRect();
for (var i=0; i<Input.touchCount; ++i) {
var t = Input.GetTouch(i);
var tpos = t.position;
tpos.y = Screen.height - tpos.y;
var pos = GUIUtility.ScreenToGUIPoint(tpos);
if (area.Contains(pos)) {
if (t.phase == TouchPhase.Moved) {
var delta = GUIUtility.ScreenToGUIPoint(
t.deltaPosition * (Time.deltaTime / t.deltaTime))
- GUIUtility.ScreenToGUIPoint(Vector2.zero);
position += delta;
}
}
}
}
(note that the conversion to/from Screen/GUI point is just to get Y going in the right direction, but it will also let you modify GUI.matrix, which can be quite useful on mobile).
No need to multiply anything by DPI. No need for magic "multiply by 3" that I have also seen others recommending.
DPI is irrelevant to touch delta position since while it is true that at higher DPI you need to move objects by more pixels, the user's finger travels proportionally more pixels too, resulting in a larger deltaPosition and cancelling out any need to consider DPI/PPI.
If all screens were the same aspect ratio and you just wanted to scale UI, you'd be right. The same UI is not appropriate for both phone and tablets.
So you think that on a tablet, dragging an object on the screen should move it by more than the distance the user's finger moves? I don't see how that is a good user experience. (nor is it what the questioner asked for as per the diagram where the object stays below the finger)
Touch.deltaTime is different between devices, so there may be a proportionate issue here. I've tried using this in an algorithm and it does not scale uniformly across devices. At least not usable for scrolling. I believe PPI (dpi) will solve this issue, but its been some time since I've gotten to work on a working solution for the app. Thats why I haven't selected an answer yet. I will give your solution a shot.
IE: PPI is a conversion from movement to inches. If I want my scroll to go X number of rows with a one inch scroll - PPI will allow for that conversion.
+1
I had a similar issue when scrolling a ScrollView or in general have the same delta speed on every device. I didn't think of Touch.deltaTime. Usually delta values, like deltaPosition doesn't need to be scaled by deltaTime since it's already a "delta value". But like you said it's not based on the visual framerate. Your fix is absolutely correct and solved all my problems ;)
Just like to add that i've found a little annoying "bug" or issue with this fix... It seems that in certain situations Touch.deltaTime can be 0. This effectively gives you the value infinity. When you add this value to your scroll position the position will end up as well as infinity. That means the scrollview totally breaks. It doesn't show any error on my device, the scrollview just disappears.
I've made a helper function to handle this:
public static Vector2 FixTouchDelta(Touch aT)
{
float dt = Time.deltaTime / aT.deltaTime;
if (float.IsNaN(dt) || float.IsInfinity(dt))
dt = 1.0f;
return aT.deltaPosition * dt;
}
Now everything is fine ;)
Again, how does PPI even relate the resolution to physical screen size?
The second P is "per".
The ratio of inches to pixels is (1 inch / Screen.dpi pixels).
So, the physical width of the screen is (Screen.width pixels * (1 inch / Screen.dpi pixels)).
I'll cancel out terms for the height result: (Screen.height / Screen.dpi) inches.
Touch.deltaPosition is also measured in pixels.
Multiply or divide as necessary to achieve the desired result.
Hmm how stable is the beta? It might work in a future solution. But definitely not on the current project.
You asked on January 23rd. If you let that same time delta pass again, I bet it won't be beta anymore. It's not like you can't rebuild the project with Unity 3.5; UT works hard to ensure this causes no problems. Your project isn't tied to a Unity release. I can't imagine anything would work well on Android without knowing the dpi - too many possibilities. The beta has been as stable for me as the 3.4 cycle.
