iDevGames Forums
NSTimer fine, CADisplayLink having some issues - Printable Version

+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: iPhone, iPad & iPod Game Development (/forum-11.html)
+--- Thread: NSTimer fine, CADisplayLink having some issues (/thread-8006.html)



NSTimer fine, CADisplayLink having some issues - monteboyd - Aug 19, 2010 06:32 PM

In a new project I started with the OpenGL ES template which checks the device's OS and uses CADisplayLink if it's available, or NSTimer if it's not.

All was working fine until I turned on accelerometer input. With the accelerometer sending input NSTimer still works exactly the same and is very smooth. But when using CADisplayLink with an animation timer of 1 (should be trying to fire 60 times a second) I get long pauses where no input seems to work (touch based or accelerometer), then the input will be received and the frame rate is just fine for a second and then another pause.

If I set the animation timer to 2 it updates consistently, but at 30 times a second and is noticeably less smooth than using NSTimer.

I can post code later (not at my laptop at the moment) but I was wondering if this is something anyone else has encountered?

I don't really have a problem with just sticking to NSTimer, but since CADisplayLink is Apple's preferred method moving forward I'd prefer to use it when available.

Thanks!


RE: NSTimer fine, CADisplayLink having some issues - AnotherJake - Aug 19, 2010 08:43 PM

Just guessing here, but on the Mac the display link fires on another thread. I forgot if that's the same on the iPhone, but I assume it is. I think the accelerometer input shows up on the main thread. Not sure if that's what the real problem is in your case, but that's the first thing that came to mind.


RE: NSTimer fine, CADisplayLink having some issues - monteboyd - Aug 19, 2010 10:16 PM

Hmmm... interesting! I must admit I'm not very up on multi threading since I've never really had to deal with it before. I'll do some Googling with threading in mind in relation to CADisplayLink and the accelerometer and see if I find anything.


RE: NSTimer fine, CADisplayLink having some issues - Skorche - Aug 20, 2010 07:10 AM

This bug has shown up since 2.x of the iPhone OS. Basically the OS starts caching events on you when you are consuming too much CPU time. It's extremely frustrating and shows up (inconsistently) whether you are using a self pumped event loop, NSTimers or CADisplayLinks. I've seen this happen in dozens of games I've played too. Increasing the thread sleep time is the only way I've been able to avoid it.


RE: NSTimer fine, CADisplayLink having some issues - headkaze - Aug 31, 2010 04:51 PM

(Aug 20, 2010 07:10 AM)Skorche Wrote:  This bug has shown up since 2.x of the iPhone OS. Basically the OS starts caching events on you when you are consuming too much CPU time. It's extremely frustrating and shows up (inconsistently) whether you are using a self pumped event loop, NSTimers or CADisplayLinks. I've seen this happen in dozens of games I've played too. Increasing the thread sleep time is the only way I've been able to avoid it.

Interesting. I wonder if adding something like the following into the main loop will help?

Code:
while(CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.002, TRUE) == kCFRunLoopRunHandledSource);

I remember reading about this line being used to clear the event queue (source)

EDIT: Adding this line to my main loop crashes my game on iPad


RE: NSTimer fine, CADisplayLink having some issues - Skorche - Aug 31, 2010 07:05 PM

No, that was what I used to do before CADisplayLink came around, and I've done it on OSX without the event queue getting clogged up. It's completely broken when compiling against the 4.0 SDK IIRC.

The really frustrating thing was that it worked differently in 2.x and 3.x. I needed to use a different delay value (your 0.002) depending on the OS version. Setting it to 0 caused severe event clogs, but the different OS versions needed different delay values to avoid it. While it was pretty hackish, using NSTimers made the framerate even less stable.