SO I have a label labelscore and it increase of 1000 every time there is a collision between two images. I would like to see labelscore increase of 1000 like an animated score, a running score. How can I do this?
You can use an NSTimer to call a routine every 16.7 to 50 milliseconds. In the routine increment some value and update it to the label. Rinse and repeat until this value is equal to the score. This is the basic technique of an animation game loop.
You have the option to use a repeating timer and invalidate it when you're done with it. Or setting single-shot timers within each update routine for the next iteration. You could also use CADisplayLink as an alternative to NSTimer, which may provide smoother animation under some conditions.
Related
I'm new to Unity and I see many times that Time.deltaTime needs to be added. In which cases should I add it? I know this is so that there will be no excess power in the event of a quick refresh of the frame's computer.
For example, in the next case, do I need to add Time.deltaTime?
playerRigidbody.AddForce(Vector3.up * 100 * Time.deltaTime, ForceMode.Impulse);
Time.deltaTime is the amount of seconds it took for the engine to process the previous frame. It's calculation is rather simple: it uses the system's internal clock to compare the system time when the engine started processing the previous frame to the system time when the engine started processing the current frame. Every motherboard has a "system clock" which is responsible to keep track of time. Operating systems have access to that system clock and provide API's to read that clock. And Unity gets the time from that API and that's how things are synchronized.
Think of a game as a movie, which is essentially a sequence of images. The difference is that a movie is rendered at a fixed rate of 24 images per second, while a game doesn't have a fixed frame rate.
In a movie, if a car travels at 1 meter per second, each image will make it move by 1/24 meter, and after 24 images (1 second) the car will have traveled exactly 1 meter. It's easy because we know that each frame takes exactly 1/24 second.
In a game, we have to do the same thing, except the frame rate varies. Some frames can take 1/60 second, some others can take 1/10 second. We can't use a fixed ratio. Instead of a fixed number we have to use Time.deltaTime. Each frame, the car will move a distance proportional to the time of the frame. After roughly 1 second, the car will have traveled roughly 1 meter
Delta is the mathematical symbol for a finite difference. Its use is very common in english when talking about something that changed over time.
deltaTime is a difference of time, so it's a Delta
Shorter Terms
You must always use Time.deltaTime when moving objects over time, either by supplying it yourself or by making use of functions like SmoothDamp that use Time.deltaTime by default (hardly any functions do that though). But you must never use Time.deltaTime for input that's already framerate-independent, such as mouse movement, since in that case using Time.deltaTime will do the opposite of what you intend.
If you're ever unsure you can always toggle vsync on and off and observe any potential speed differences. If the game's already running close to the monitor refresh rate anyway, then make use of Application.targetFrameRate instead.
In very easy words
Time.deltaTime is the time passed since last frame was rendered.
By multiplying a value with it you basically convert it from Something per frame into Something per second.
Is it needed?
Now if you need to use it totally depends on your specific use-case! In your case for AddForce: NO!.
The force influences the velocity of a physics object. The velocity itself already is an absolute per second vector.
Usually there are two use-cases for AddForce:
It is called continuously but within FixedUpdate
Because FixedUpdate is not called every frame anyway but rather on a fixed real time intervals (by default 0.02 seconds) you would not need Time.deltaTime. The Doc already provide this in the example.
It is anyway called only as a single event (e.g. by jumping)
Here there is nothing continuous, so you don't need and don't want to use Time.deltaTime either since a single event can not be frame-rate-dependent anyway.
I am wondering if there is a way to make a UISlider move smoothly like the one in music App. Without steps and jumps. Just move till the end. I am currently using CADisplayLink to update the slider, the only problem is that the slider just jumps to the next value even when animated is set to true. This looks bad with values under 2min.
I am a bit confused by your question, but if your slider is very erratic and jumps to values the user did not set, I would recommend increasing the size of the element on your view controller.
If that doesn't work, you could scale your minimumValue and maximumValue by a factor of ten and then divide by ten when actually doing calculations with your UISlider. What I mean by that is:
multiply min and max values by 10
Keep a variable of the actual value you want to use
Save your value and divide by 10 whenever the user sets a new value in the UISlider
I have a game where I use a lot of SKActions to deliver the desired game logic.
For example, instead of setting the zRotation of a sprite to a value, I would use runAction(SKAction.rotateTo(/* angle here */, duration: 0.0) instead.
I make calls like this in update, and in touchesMoved. Thus this could mean hundreds of these calls, sometimes nested with groups of other actions.
Am I incurring significant overhead relative to directly setting the zRotation property?
Never use SKActions for real-time motion. Instead you should either set the zRotation directly or set the necessary angular velocity each frame. In your case the update method and touchesMoved method are both bad to use for SKActions because they can run 30-60 times a second.
SKActions do generate significant overhead. Here is a quote from Apple's documentation:
When You Shouldn’t Use Actions
Although actions are efficient, there
is a cost to creating and executing them. If you are making changes to
a node’s properties in every frame of animation and those changes need
to be recomputed in each frame, you are better off making the changes
to the node directly and not using actions to do so. For more
information on where you might do this in your game, see Advanced
Scene Processing.
Source
You can see an example of using real-time motion instead of SKActions in my answer here
You should not call a SKAction in the update method as it is called 60 times a second. Instead, use a event based trigger which in turn calls the SKAction. The touchesMoved is a good example of that. You can also use a completion method block to signal for a new SKAction upon completion of the current action.
Hi all can anyone help me out with the solution to this problem...
I have a project where I have NSTimer fire about 20 times a sec and thus using only one image(loaded programatically)produces the same image on the iPhone screen about twenty times in a second and these images fall from the top of the screen to the bottom where they are removed(more or less simulating rain fall or rain droplets).
My problem is that looking at the animation, I noticed that there are very small delays and which looks like a break, pause or small vibrations. Thus the flow isn't smooth.
Can anyone help me with the solution please.
Thanks in advance
You can check the CADisplayLink class.
Just because you ask for a timer in the UI run loop to go off at a certain rate, doesn't mean you will get called at exactly that rate or at evenly spaced intervals. You should check the time and the elapsed time "dt" inside each timer callback, and change your animation position, y + dy * dt, etc., accordingly.
Timer's arn't designed to be used for animation.
The best thing to do, is to have a thread running in an infinite loop, where you check if it's time to animate again, or just always animate (giving you a higher frame rate), but using the time elapsed as a reference for the state you are drawing.
You really shouldn't be using a timer for this. Instead you should be using the built in UIView animation methods:
animateWithDuration:animations:
animateWithDuration:animations:completion:
animateWithDuration:delay:options:animations:completion:
I am using about 20 UIImageViews of small airplane images (50x50 pixels) doing simple animation on the iPhone screen. The animation is done by shifting the UIImageView center property at timer interval.
[NSTimer scheduledTimerWithTimeInterval:0.01
target:self
selector:#selector(timerFired:)
userInfo:nil
repeats:YES]
What is the best practice: create one NSTimer and loop the 20 UIImageViews to set the center property when timer fired? Or should I just create one NSTimer per UIImageView object? Is NSTimer resource expensive?
I don't think it's that resource intensive, but common sense would seem to dictate that using 1 timer is probably better than 20.
Looks like your timer is set to fire 100 times per second, which seems a bit excessive. Do you animate each sprite at every timer firing? Might want to try firing 20-30 times per second instead (or maybe even less).
You might want to look into the built in view animation functions as well. Seems like they would probably work very well for what you are doing.
you could try both and use the built in profiling tools that ship with Xcode to gauge resource usage.
Timers are actually PRETTY EXPENSIVE, energy-wise.
Every nanosecond that the OS (or apps running on it) are not doing something, the CPU is sleeping in one of several low-power state modes. Waking the system from an idle state incurs an energy cost when the CPU and other systems are awakened from their low-power, idle states. If a timer causes the system to wake, it incurs that cost. The more frequently your timer fires, the higher the energy cost. On mobile devices, it can affect materially battery life.
In that sense, it is much more efficient to wake the system once, do all your work, then let it sleep again for as many nanosecs as possible. Going back to your example, if you profile this, it should be more efficient to use 1 timer rather than 20 timers, each firing 100 times / sec.
Later OS versions allow you to specify a tolerance (in %). This allows the system to group timers together and execute them at the same wake event, to save power. It seems what you are doing is not time critical (in a real-time execution kind of sense), so permitting a tolerance (e.g. 10%) should help.
Example: [myTimer setTolerace:0.3];
More about timer tolerance here: https://developer.apple.com/documentation/foundation/nstimer
Instead of attempting to have a Timer synchronized to the screen redraw (i.e. firing 60x a second), a better solution would be to use CADisplayLink, which fires as on screen redraw and is built for this purpose.
let displayLink = CADisplayLink(target: self, selector: #selector(displayLinkFired))
displayLink.add(to: .main, forMode: .default) // attach to the main run loop
#objc func displayLinkFired() {
// update image view's here
}