koobas.hobune.stream
Using Time.deltaTime to increase value gives constant values
Hello All.
So I am making a 3-click power/accuracy system that is often used in sports games especially golf. The problem is I have a dial(See Below) along with a needle that has to move from 0° to 225° in a specific time frame(1.7 seconds) On the way back down the user has to stop the needle as close to the yellow line to determine his accuracy in degrees.
To do this I did the following: To move 225° in 1.7s, divide both sides by 1.7s to get that in one second the needle has to rotate about 132°. So to move the dial I have the following in my script:
float Rotation = 0;
void Update()
{
Rotation -= Time.deltaTime * 132;
}
This works for rotating the needle 225° in ~1.7 seconds without a problem, however the Rotation value is also used to determine accuracy when the player stops the needle by clicking.
And this value is returning consistent values because of time.deltatime.
To explain, say I get 60 fps, as far as I understand the value of time.deltaTime will be 1/60=0.0167 more or less.
Meaning the result of
Rotation -= Time.deltaTime * 132;
will more often than not be an increment of 2.2° per frame, so mostly the resulting accuracy values of the player will be multiples of 2.2° and not any value in between, which is not ideal.
So I am looking for a way I can achieve smaller increments(Ideally smaller than 1°) but keep the same time frame? What I have thought of doing is splitting the
Rotation -= Time.deltaTime 132;
statement into two(or more, using a for loop)
Rotation -= Time.deltaTime 66;
statements. But I am not sure if this will have any effect.
you have some problems, in the first instance learn about FIxedUpdate as an alternative
Unity Input.xxxx values don't change during Update calls so if you read values from Input.Get$$anonymous$$eyDown for example, using FixedUpdate won't change anything.
Did they add a way to catch input events asynchronously in some recent Unity version or was i just drea$$anonymous$$g ? Someone re$$anonymous$$d me :)
quite, the question was far too confusing to read (I have no idea if Input is even the issue here?), but I observe the OP doesn't know about FixedUpdate so thought it might be a place to start :) Good on your for trying to help
Same to you! Didn't mean to sound uptight... if i did
OP you realize Time.deltaTime can/is different each time (especially in 'real life' use). did you read the manual entry http://docs.unity3d.com/ScriptReference/Time-deltaTime.html particularly in regard to OnGUI
Update() is called once each frame causing you to change Rotation by no less than AngleSpeed/FPS degree. AngleSpeed is TargetAngleChange/TimeToChangeAngle Which means 225/(1.7*60)=2.2. You either need to disable FPS limit, or use some other was of setting Rotation more often than 60 times per second (another thread without waiting for example. It will use one full CPU core though).
One basic answer here is that game engines are indeed literally frame based.
Sure, you can look in to fixedDeltaTime and so on but it's just "not a thing" on touch screen devices/gaming.
Imagine you were a film maker (think of old fashioned plastic film which runs at 24 fps). You are asking "how do I do such-and-such at a higher time resolution?" Well, of course you absolutely simply can't.
Just purely FYI....
in video games when exactly this happens, you just randomly add a small amount, i.e. you randomly pick a value inbetween the last and next frame time.
1 - it's inconceivable you could get anything "more precise" than this, given the vagaries of touch-screen devices, OSs
(Note for example, say Apple themselves were offering, let's say, a "scientific stopwatch" or something lke that - even them being able to program at the system level. It would be nonsensical on a touchscreen device.)
2 - it's just a video game - nobody cares.
Note that this question is a many times duplicate.
For example here is one of the top-5 Unity scientific engineers explaining the situation
http://answers.unity3d.com/questions/52787/reaction-game-measure-time-of-touch-exactly.html
That link sums it up pretty well, mostly the comments about reaction time and frames.
But, the one thing that doesn't apply is 0.25 second reaction time. That's "see and respond" time. I'd imagine someone can tap a standard power-meter a little more accurately, since it's using a mental clock, and not reaction speed.
Thanks guys for all the feedback, I appreciate it and sorry for the long and confusing post.
Essentially all of your explanations and that link did help me better understand. Essentially the answer to my problem is in it self it can't be changed or solved, as you state in your answer, engines are frame based so it can only go so small. I did end up using fixedUpdate and adjusting the fixed time step ever so slightly, and things are better now thanks.
Also one thought I had when Owen Reynolds said it is more of a mental clock and ti$$anonymous$$g than response, I thought of just getting the difference in time between the clicks(since that should be very small values and accurate) then convert the time to the values I need. But so far I haven't tried it so I might be missing something.
If you think of it as how many Update calls they have to tap in each area, I think your problem goes away.
If you're getting 60 fps, that's 60 Update calls in a second, at 17 milliseconds each. I think that's way below the tolerance of human reaction time. Suppose they have to tap during an exact 10th of a second -- that's 6 frames. Jumps/drops in frame rate and exactly when they happen will change it some, but not by much.
I think that's why input is only checked once/Update. 60FPS is fine-grained enough (it only draws that often -- a bar jumping by 2 degrees looks smooth to us.)
Indeed, as I mentioned in actual buy-in-the-shops video games when the "reaction timer" displays anything more than about 15Hz (far less 60), the programmers simply pick a random value so it looks cool.
I guess, Unity could add a field to touch "exact time touch noticed" (if such a thing is even available from the OS) but it would be BS< given the vagaries of touchscreen technology.
