I am a newbie at ladder logic. The program linked below runs a timer, and updates the delta time between each "frame".
https://www.plcfiddle.com/fiddles/e56c6cf0-d858-4327-b291-7cdc1067ffc1
The preset value for the timer is set to 10, so the timer stops after 10 seconds. I want this timer to run indefinitely. My first guess is to set the preset value to 0 (or a negative number), but this prevents the timer from running at all.
How can I make this function run indefinitely?
No need to run the timer indefinitely, just reset the timer each scan (no such thing as a frame where I come from).
See this updated fiddle.
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.
I have two timers running simultaneously. The first timer triggers every 1 second and takes 0.2 seconds to run. The second timer triggers every 20 minutes and takes 5 minutes to run. I would like to have the first timer continue triggering during the 5 minutes it takes the second timer execute its callback. In practice, during the second timer's callback the first timer does not trigger. Is it possible to configure the timers to execute the way I want?
There is a workaround, depending on how your timer callbacks' work is structured. If the long timer callback is running a long loop or sequence of calls to different functions, you can insert drawnow() or pause(0.01) calls to make it yield to Matlab's event dispatch queue, which will handle pending handle graphics and timer events, including your other Timer's trigger.
It's sort of like old-school cooperative multitasking where each thread had to explicitly yield control to other threads, instead of being pre-empted by the system's scheduler. Matlab is single-threaded with respect to M-code execution. When a Matlab function is running, events that get raised are put on an event queue and wait until the function finishes and returns to the command prompt, or drawnow(), pause(), uiwait() or a similar function is called. This is how you keep a Matlab GUI responsive, and is documented under their Handle Graphics stuff. But Matlab timer objects use the same event queue for their callbacks. (At least as of a couple versions ago; this is only semi-documented and might change.) So you can manage their liveness with the same functions. You may also need to tweak BusyMode on your timers.
This is kind of a hack but it should get you basic functionality as long as you don't need precise timing, and don't need the callbacks' code to actually run in parallel. (Whichever timer callback has yielded will wait for the other one to finish before proceeding with its own work.)
If the long callback is really blocked on a long operation that you can't stick drawnow calls in to, you're out of luck with basic Matlab and will need to use one of the workarounds the commenters suggest.
I am developing an iPhone game and I have an NSTimer that animates all of the objects on the screen:
EverythingTimer = [NSTimer scheduledTimerWithTimeInterval:1.0/30.0 target:self selector:#selector(moveEverything) userInfo:nil repeats:YES];
Most of the time it runs very smoothly, but sometimes I see things move slower or choppy. I have pause and resume functions that stop and start the timers respectively. When I pause then unpause, it seems to fix the choppiness.
Any ideas to why this is happening? or How can i fix it?
Any ideas to why this is happening?
The short answer is that in your case, you are performing actions (animations) based on an unsynchronized push model, and the mechanism you are using is not suited for the task you are performing.
Additional notes:
NSTimer has a low resolution.
Your work is performed on the main run loop. The timer may not fire when you expect it to because much time may be spent while work on that thread is underway, which blocks your timer from firing. Other system activities or even threads in your process can make this variation even greater.
Unsynchronized updates can result in a lot of unnecessary work, or choppiness because the updates you perform in your callback(s) are posted at some time after they occur. This adds even more variation to the timing accuracy of your updates. It's easy to end up dropping frames or perform significant amounts of unnecessary work when the updates are not synchronized. This cost may not be evident until after your drawing is optimized.
Out of the NSTimer docs (emphasis mine):
A timer is not a real-time mechanism; it fires only when one of the run loop modes to which the timer has been added is running and able to check if the timer’s firing time has passed. Because of the various input sources a typical run loop manages, the effective resolution of the time interval for a timer is limited to on the order of 50-100 milliseconds. If a timer’s firing time occurs during a long callout or while the run loop is in a mode that is not monitoring the timer, the timer does not fire until the next time the run loop checks the timer. Therefore, the actual time at which the timer fires potentially can be a significant period of time after the scheduled firing time.
The best way to remedy the issue, if you are prepared to also optimize your drawing -- is to use CADisplayLink, as others have mentioned. The CADisplayLink is a special 'timer' on iOS which performs your callback message at a (capable) division of the screen refresh rate. This allows you to synchronize your animation updates with the screen updates. This callback is performed on the main thread. Note: This facility is not so convenient on OS X, where multiple displays may exist (CVDisplayLink).
So, you can start by creating a display link and in its callback, perform work which would deal with your animations and drawing related tasks (e.g. perform any necessary -setNeedsDisplayInRect: updates). Make sure your work is very quick, and that your rendering is also quick -- then you should be able achieve a high frame rate. Avoid slow operations in this callback (e.g. file io and network requests).
One final note: I tend to cluster my timer sync callbacks into one Meta-Callback, rather than installing many timers on run loops (e.g. running at various frequencies). If your implementations can quickly determine which updates to do at the moment, then this could significantly reduce the number of timers you install (to exactly one).
NSTimers are not guaranteed to run at exactly the rate you asked for. If you're developing a game, you should investigate CADisplayLink, which implements roughly the same interface as NSTimer but is fired at every screen redraw.
You set up a display link just like your timer, only you don't have to specify a refresh period.
CADisplayLink* displayLink = [CADisplayLink displayLinkWithTarget:self selector:#selector(moveEverything)];
[displayLink addToRunLoop:[NSRunLoop mainRunLoop] forMode:NSRunLoopCommonModes];
Above all you should measure the amount of time that has passed since the last iteration. Don't rely on it being exactly 1/30th or 1/60th of a second. If you have code like this
thing.origin.x += thing.velocity * 1/30.0;
change it to this
NSTimeInterval timeSince = [displayLink duration];
thing.origin.x += thing.velocity * timeSince;
If you need a high-precision timer for a reason other than making a game, see Technical Note TN2169.
As Hot Licks suggested, 30 Hz is reasonably fast, so depending on what you're doing inside moveEverything, you might simply be overwhelming your phone's processor. You don't show moveEverything, so we can't really comment on what's inside ... but, you may need to work at making that method more efficient, or slowing down the rate at which your timer fires.
Also, it's possible that your NSTimer is simply not firing at times, because the timer has not been added for all the right run loop modes.
For example, when a scroll view scrolls (a performance intensive operation), the UI is in tracking mode. By default, the way you've created your timer, the timer will not fire when in tracking mode. You can change this by using something like this:
EverythingTimer = [NSTimer scheduledTimerWithTimeInterval:1.0/30.0
target:self
selector:#selector(moveEverything)
userInfo:nil
repeats:YES];
[[NSRunLoop mainRunLoop] addTimer:EverythingTimer forMode:NSRunLoopCommonModes];
I'm polling a router from an iPhone. The timer only fires every 60 seconds. I'm starting the timer in ViewDidLoad and leaving it on.
There's a flag pollingON initially set FALSE.
When the timer fires, it calls myTimerFiredMethod, which then checks,
if (self.pollingON) {
self.pollingON = FALSE ;
// run the polling code
self.pollingON = TRUE ;
}
Aside from wasting a nanosecond or two of CPU time, anything wrong with this practice?
A timer that is running although not in use, is a waste of battery life. It's also a strange design pattern, running a timer without a cause.
Also if you turn on Polling, at worst you will have to wait almost 60 seconds before an update.
I would not recommend implementing it that way. Instead, invalidate the timer when polling is turned off and create a new timer when polling is turned on.
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.