koobas.hobune.stream
How to lower float value A as float value B gets bigger?
I'm trying to slow down a touch finger move as I get farther away from the start position. Here's what I currently have, which keeps the same speed no matter what:
using UnityEngine;
using System.Collections;
public class Swipe : MonoBehaviour {
public float speed = 2f;
public Vector2 moveAmount;
public Vector2 startPos;
public float minSwipeDist = 30f;
public float comfortZone = 70f;
public float swipeDirection;
void Update ()
{
if( Input.touchCount > 0 )
{
// Store GetTouch(i) into "touch" variable...
Touch touch = Input.touches[0];
// Store the swipe distance
float swipeDist = (touch.position - startPos).magnitude;
switch( touch.phase )
{
case TouchPhase.Began:
startPos = touch.position;
break;
case TouchPhase.Moved:
moveAmount += touch.deltaPosition * speed * Time.deltaTime;
**moveAmount *= (minSwipeDist - swipeDist) * 0.01f;**
print("Move Amount: " + moveAmount );
break;
case TouchPhase.Stationary:
moveAmount = Vector2.zero;
break;
case TouchPhase.Ended:
//print("Swipe Distance: " + swipeDist );
if( swipeDist > minSwipeDist )
{
swipeDirection = Mathf.Sign( touch.position.x - startPos.x );
}
break;
}
}
}
}
The BOLD line in the code above is where I'm stuck. I'm trying to multiply the moveAmount Vector2 by the distance since the swipe started so that "moveAmount" gets lower and lower as I slide the finger across the screen, slowing down the swipe.
I know I'm missing something silly, but I don't see it yet...
Thanks in advance for any help, greatly appreciated as always!
What you want is a non-linear relationship.
moveAmount = (minSwipeDist - swipeDist) 0.01f;
This is linear relationship: as swipeDist increases moveAmount increases a proportional amount.
Here is a simplified version of that relationship:
y = (x + a) * c
where a and c are constants.
since it is linear you can say y is proportional to x.
y ∝ x
There are variety of simple non-linear relationships for example:
y ∝ x^(2)
Here y is proportional to x squared so y grows faster than x, which the opposite to what you want. Let's turn it around:
y ∝ x^(1/2)
Here y increases as x increases but slowly. Squareroot is an expensive operation though so let's look for something simpler.
Consider:
y ∝ x / (x+c)
let's subsitute some values and see.
y = x / (x + 4)
x = 0, y = 0
x = 1, y = 1/5 = 0.2 diff = 0.20
x = 2, y = 2/6 = 0.33 diff = 0.13
x = 3, y = 3/7 = 0.42 diff = 0.09
x = 4, y = 4/8 = 0.5 diff = 0.08
x = 5, y = 5/9 = 0.56 diff = 0.06
You can see it still increases but the difference is getting smaller as the number get's larger.
Hope that answers your question.
you can also do the same very simply with y=1/x x=1, 1/1=y=1. x=2, 1/2=y=0.5. x=3, 1/3=y=0.333
Hey guys thanks a lot for the examples! This is exactly what I needed. One thing though, isn't division much more expensive then multiplication? How would I write the above using multiplication ins$$anonymous$$d of division?
firstly I'm not totally sure about the expense but despite division having a greater impact than multiplication I would doubt either would effect the speed much unless you are doing this in 100 different scripts every frame. the way that you get the same effect would be by timesing by 0 point something however I don't know how you would use this with you variables. The other way as Anxo said above would be to have a max speed variable say 100. then do speed = maxspeed - distance = at 0 distance the speed is maxspeed however as the distance increases the speed will decrease 100-50 = 50 so the speed would be 50. the problem with that method would be that if the distance was equal to or greater than maxspeed it would stop and then go the otherway. I would suggest using / and if after you have finished it makes a significant difference to performance ask again.
"Premature optimization is the root of all evil." It's a bit of an over statement when developing for phones but there is still some truth to it. As Scribe pointed out you would have to be doing this calculation many times per second to see a significant performance hit, in which case you could optimize it by precalculating values in a lookup table.
