Just curious as to people's experience using NSTimer. It seems to be working well for me so far, but I'm a bit concerned that if the system gets bogged down a bit that it could potentially get inaccurate? Accurate timing is pretty important to my game (a music rhythm based game) and I'm purposely limiting the processing my game is doing in order to do my best to ensure things run smoothly and my timer keeps firing accurately.
In my experience, the timer events will just get dropped when the system is too busy. You should profile your app and make sure the timer callbacks keep happening in time.
I've not used the timer in Objective C, but in all other languages/platforms, the delay that you set for the timer is not necessarily accurate. For example, a timer object set to 1000ms delay is not guaranteed to go off every 1 second, in fact, under heavy usage, there is a noticeable difference. I've solved similar problems by increasing the rate of ticks so that you are working with frames (ie 30fps) rather than with seconds, and then do a call to get the system time to time how fire your events.
Thanks! Anyone have any tips as to how to stress out the iPhone/iPod to simulate a low resource environment that might cause inaccurate timers? Like maybe surfing to a ton of sites in Safari, opening the max number of browser instances, playing a bunch of games, etc.. And then starting up my game?
That won't help, because all those other things will be shut down when your game is started up. The easiest thing to do is make your drawRect method very inefficient (or cause full-screen invalidates where partials would have sufficed). That's how I found out, myself
We had the same problem, NSTimer can be really inaccurate. Sudden drops form 30 fps to 15 fps. Sux. We've tried many different solutions such as separate threads and using higher timer resolutions, and we're stuck with just using a timer rate of 120 instead of the 30 we aim for. Works fine so far. But make sure your game loop has fixed time increments. -- Volker
Thanks, yeah, it's definitely a bummer. Mainly what my timer callback is doing is setting off Core Animations.. and in my case I can get away with retiming my animations based on how far off the timer is. So if the timer was late by 20ms, I can make the animation run 20ms faster to still finish at the correct time. So far it seems to be working okay, I have enough leeway where I don't think it will be too perceptible to the user. I can also get away with upping my timer rate to put less stress on it as well. But this is all definitely some good information to know going forward.. I'll know not to rely on NSTimer being gold.
Be careful with this and make sure you test on the 1st gen iPod Touch, the slowest of all the devices. I had a timer firing at ~240Hz which it (1st gen iPod Touch) couldn't handle...I had to reduce it to ~80Hz which might've degraded performance on the faster devices, but there isn't a reliable way to test which device you are running on.
As far as I understand: When the machine is too slow, the timer event sequence will be subsampled. ie. instead of 240hz, you get 120hz. If you have a fixed timestep simulation in your game and some smart logic, that shouldn't be a problem. Or am I missing something?
I can't tell you why it broke instead of just slowing down considerably, you are right that in theory it shouldn't happen. I'm just advising to always test on the worst device, because I've found rather extreme differences when using timers.
