What is the best way to handle this situation on an iPhone device: My program ramps the pitch of a sound between two values. A button pressed calls a method that has a while loop that does the ramping in small increments. It will take some time to finish. In the meantime the user has pressed another button calling the same method. Now I want the loop in the first call to stop and the second to start from the current state. Here is the something like what the method should look like:
-(void)changePitchSample: (float) newPitch{
float oldPitch=channel.pitch;
if (oldPitch>newPitch) {
while (channel.pitch>newPitch) {
channel.pitch = channel.pitch-0.001;
}
}
else if (oldPitch<newPitch) {
while (channel.pitch<newPitch) {
channel.pitch = channel.pitch+0.001;
}
}
}
Now how to best handle the situation where the method is called again? Do I need some kind of mulitthreading? I do not need two processes going at the same time, so it seems there must be some easier solution that I cannot find (being new to this language).
Any help greatly appreciated!
You cannot do this like that. While your loop is running no events will be processed. So if the user pushes the button again nothing will happen before your loop is finished. Also like this you can’t control the speed of your ramp. I’d suggest using a NSTimer. In your changePitchSample: method you store the new pitch somewhere (don’t overwrite the old one) and start a timer that fires once. When the timer fires you increment your pitch and if it is less than the new pitch you restart the timer.
Have a look at NSOperation and the Concurrency Programming Guide. You can first start you operation the increase the pitch and also store the operation object. On the second call you can call [operation cancel] to stop the last operation. Start a second operation to i.e. decrease the pitch and also store the new object.
Btw: What you are doing right now is very bad since you "block the main thread". Calculations that take some time should not be directly executed. You should probably also have a look at NSTimer to make your code independent of the processor speed.
Don't use a while loop; it blocks everything else. Use a timer and a state machine. The timer can call the state machine at the rate at which you want things to change. The state machine can look at the last ramp value and the time of the last button hit (or even an array of UI event times) and decide whether and how much to ramp the volume during the next time step (logic is often just a pile of if and select/case statements if the control algorithm isn't amenable to a nice table). Then the state machine can call the object or routine that handles the actual sound level.
Related
I am curious what to use for my game. A timer:
let goodFPS = SKAction.wait(forDuration: 0.01666)
let mainGameRunner = SKAction.run {
//my code is here
}
let toRepeat = SKAction.repeatForever(SKAction.sequence([goodFPS,mainGameRunner]))
inGameHighScore.run(toRepeat,withKey:"mainGame")
or the update function:
override func update(_ currentTime: TimeInterval){
//my code is here
}
Which provides faster more consistent updates?
note: my frame rate is in the range of 45 to 58
First I think you are taking the FPS problem the wrong way around. You cannot "force" a faster frame rate than the device can give you. If you are basing the movements in your game on the assumption that every frame will be consistent, you are doing it wrong. It's actually how they did in the early days because CPUs were so slow and the difference from one generation to the new one wasn't too bad at first. But running an old DOS game on younger hardware will be tricky because the framerate is so high that the whole game mechanic becomes unstable or simply too fast to be playable.
The concept here is to think "over time" and to scale down any action in relation with the time elapsed between two frames.
The update() method gives you that opportunity by providing the current system clock state every frame. By keeping track of the time on the last frame, you can calculate the time difference with the current frame and use that difference to scale down what you are doing.
Using a timer to get the update on a consistent frame rate is not recommended nor practical. You may be calling the update closure at a given time interval, but the code inside that closure is taking time to execute on its own, and depending on your game logic, it might even have different execution times. So maybe the pause timing is consistent, but the code running before and after that pause might not be consistent. Then what happens if you run your game on a slower CPU? The code speed will change even more, making your timing inaccurate.
Another point against using an SKAction for your game loop is simply what they are. An action is an object in memory, meany to be reused by multiple objects. If you are making a "jump" action, for example, it is recommended to store that action somewhere and to reuse the same object every time you need something that "jumps", no matter what node it is. Your game loop is meant to be executed every frame, but not by different objects. Actions are also disposable. Meaning that you can kill an action even while it's running. If you put your game loop in an action, it will probably be run by the SKScene. If you use another action on your scene it becomes a puzzle right away because there are only two ways of removing an action besides letting it come to term: removing all actions or creating the action with an identifier key and use that key to remove any action with that key. If you don't see it already, it then forces you to put identifiers on every action that will be run by the scene and remove them one by one. And them again it leave a door open for a mistake that will get rid of your game loop because, keep it in mind, actions are DISPOSABLE! Then there is also no guarantee that your action will get executed first every single frame.
Why use the update() method? Simply because it is built IN your scene. No matter what, every frame, update() gets called first. THEN, the actions get executed. You cannot flush the update() method accidentally like you can with an action. You don't have to be careful about strong/weak relationships causing memory leaks because you are referring to objects from inside a closure like you do with an action.
Suggested reads:
SKAction API reference
SKScene API reference : read about the frame processing in SpriteKit. It will help you understand how they put everything together at every frame.
I hope it makes things clearer.
I'm pretty sure that SKAction's timing facilities are based on the same game loop that is calling update.
The advantage of SKAction is that it's fire and forget for you, while using update would get awkward with setting and checking a bunch of timer variables.
I don't have a ton of experience with SpriteKit but I do have some experience making games and animations in iOS.
There is a class called CADisplayLink that fires a call to a delegate every time the screen is refreshed, this is a great way to update the screen, either in a game or in an animation, because you can know it will be called every frame and no more.
I'm not sure if SpriteKit uses that class to fire the update method, but I'm sure it uses something similar. This is usually called the run loop.
SKActions run on top of this run loop.
By creating your own run loop using a wait action, not only you're not gaining any benefits, you could be introducing inconsistencies in the way your logic is run.
Imagine that you have your wait action set to 0.01 seconds (I rounded it down for simplicity). If the screen is refreshing faster than you expect, and the action is updated every 0.009 seconds, the first time it's checked, it won't fire because there's a remaining 0.001 second on the wait command, so another 0.009 seconds will pass, and your code will be executed after 0.018 seconds, instead of your desired 0.01. Not only that, but two frames will have passed between the execution.
If you use the update function, you can know that your logic will be executed once every screen refresh, and no more.
We know there's a "rule" that Input functions shouldn't be used inside the FixedUpdate(); Input.GetKeyDown() may not work if we do so, but is it really wrong to use Input.GetKey()?
Let's say we want to fire something when pressing and holding a key at some rate that is not dependent on hardware performance. I don't want to create a logic to control this using delta time or writing key detection code in Update and firing code in FixedUpdate.
Doesn't make sense to just do everything inside FixedUpdate? What can happen - we may lose some key pressed events, the ones that we didn't want anyway, to keep our desired rate.
But what if one single key event happens, can we lose it? Is there a reset after Update, so we won't see it on FixedUpdate?
From the GetKeyDown docs:
You need to call this function from the Update function, since the
state gets reset each frame
So yes, the Input state is reset each frame meaning hardware will have an effect depending on how frequently Update fires between FixedUpdate.
There really isn't an easy way to avoid creating a copy of the Input that is used by FixedUpdate, though I would suggest reevaluating your logic to move things in to Update.
Update:
Regarding Rutter's comment below. I just noticed the OP was asking about GetKey(), what I wrote about GetKeyDown() remains true for GetKey() though the documentation doesn't explicitly say so.
This can be verified by going in to the Time Manager and changing the FixedUpdate rate to some long interval like 1 second. Then do something like:
void FixedUpdate() {
if(Input.GetKey(KeyCode.D)){
Debug.Log("D-Key Down");
} else {
Debug.Log("No key down");
}
}
If you press and release 'D' between the 1 second fixed frames you will only see "No Key Down".
In my experience, Update occurs at frame-time, unlike Fixed Update which can occur multiple times per-frame. In addition, The physics of objects are actually updated before FixedUpdate() is called, which means there could be a delay based on the complexity of the scene.
I believe that Input is actually broadcasted per-frame, so when the FixedUpdate() is behind and needs to catch up by firing multiple times, the Input check will fail.
Additional Resources:
http://answers.unity3d.com/questions/10993/whats-the-difference-between-update-and-fixedupdat.html
I need a button to do different things depending on how far along the person is in watching a video.
So for instance at 0-20 seconds it does thing A
then at 20-25 it does thing B
and 25-32 thing C
Can I make a timer that counts up and fires different messages off at specific intervals to enable/disable my buttons or change what they do?
Or should I have it fire and simultaneously start another timer and change what my button does and form a chain of events?
Thanks!
do an if statement so if timer >0 and <20 seconds make button event a, if timer is >20 and <25 make button event b and so on.
This way when a user clicks on the button depending on what time the timer is on then it would have changed appropriately anyway.
What you can do however which i think would be even convenient is to allow the user to press the button at anytime anyway but before any code is executed check the current position of the timer, and if the timer is > 0 but < 20 then execute EVENT a, and if timer > 20 but < 25 then execture event B this way you dont have to change the buttons but simply redirect the code that gets executed just by checking the current position of the timer. And this way there is only one timer involved.
Hope that made sense.
Its much more simpler like this rather than having the timer simultaneously fire another time, creating more timers means more objects needed to be created meaning more things to manage.
However if you want to fire multiple events and you prefer to do it that way then you do this:
http://howtomakeiphoneapps.com/2010/03/how-to-make-an-egg-timer-for-your-iphone/
Sorry i wrote this in psuedo style but im sure you have enough to understand what i am saying.
PK
NSTimer has a method setFireDate:(NSDate *)date, so instead of creating a chain of timers, you can have one timer and reschedule the next fire time as needed. Just make sure that your timer interval is large enough so that the timer won't fire before you get a chance to reschedule it.
Default action is A
Set up a timer for B and one for C. When B-timer fired set current action to B. When C-Timer fires set current action to C.
For Stage Time I set up one repeating timer as the countdown timer. On each fire, I would check the time remaining and update various UI bits appropriately.
For your app, I would go with the repeating timer approach only if I had plans for other time-based features in future releases or if I wanted to dynamically change the times for event A, B and C. Otherwise, I'd probably set up three timers at the beginning, one each for events A, B and C. That way the logic managing the time partitioning is all in one place, likely the AppDelegate, and the button change logic can all live in the View Controller.
What I am doing right now is starting the timer with interval of 1 and repeat: YES
When it fires it calls a method which simply increments seconds(int)
Within this method, which is called every 1 second, I will use a switch statement to check the value of seconds and if it is a certain value it will pause my player and invalidate the timer.
This should pause the video and stop my seconds from being incremented.
I will then have a button for the user to resume the video which will play the vid and begin the same timer again and resume incrementing seconds.
My only worry is that the second count may not be accurate to the video because of processing delays at runtime dealing with the video and the switch statement being checked. I'll report back how it works.
What I want to do is have a while statement which loops whilst the recorder.recording property value is set to YES. So, something like:
while (recorder.recording == YES)
{
// Do something here until the record button is pressed again
// Stop the recorder from recording and break out of loop
}
Problem I'm currently facing is that the UI becomes completely frozen due to the while loop. Any ideas?
Either use an NSTimer to perform the action at a given time interval while the recorder is recording or look into using a separate thread to do your loop work on.
Tight loops like this will block the UI if done on the main thread, because that's where the UI is running.
I'm developing a game in which I'm reducing the frame size of an imageView. When I'm introducing a condition using while loop, I'm not able to see the image reducing its size gradually, since it immediately jumps to the final result. So, I want to introduce a delay after every instruction so that I can see the effect of its size reduction little by little.
I can't use timer since it needs me to specify a function to be executed after that time interval.
while(ravanImage1.frame.origin.y>=end.y)
{
ravanImage1.frame=CGRectMake(150,((ravanImage1.frame.origin.y)-5),q,z);
if(ravanImage1.center.y>=300&&ravanImage1.center.y<=370)
{
q=60;
z=60;
ravanImage1.frame=CGRectMake(150,((ravanImage1.frame.origin.y)-5),q,z);
}
if(ravanImage1.center.y>=230&&ravanImage1.center.y<=299)
{
q=40;
z=40;
ravanImage1.frame=CGRectMake(150,((ravanImage1.frame.origin.y)-5),q,z);
}
if(ravanImage1.center.y>=150&&ravanImage1.center.y<=229)
{
q=20;
z=20;
ravanImage1.frame=CGRectMake(150,((ravanImage1.frame.origin.y)-5),q,z);
}
}
I want to introduce delay after every frame change.
Can anybody please help me?
How about using
[NSThread sleepForTimeInterval:]
inbetween every instruction?
If you just need to pause the change during development, use the debugger's breakpoints.
For release, you should use an animation block to make the changes. Create a separate block for each possible change and then set the animation duration to what you'd like.
As a general rule, you never change the frame of a view directly anymore unless you wish it to be instantaneous. Animations exist precisely for this purpose i.e. to create an effect that communicates a change in view state to the user. They're not just eye candy.
If for some reason, you don't want to use animations, you could move each size change into it's own method and then call each method with a timer. You could call the first method, which would set a timer to call the second, which would set a timer to call the third and so on.
So use the timer and give it a function which will take up the right amount of time to execute but have no impact on your display ? Maybe run a long loop of meaningless calculations at the right place in your program ?