UPDATE I think I solved this one, though any thoughts or suggestions are always welcome!

This one is truly bizarre... I'm developing using both an iPhone 3GS and an iPad 2. This symptom is repeatable on the older iPhone hardware much more readily than on the iPad 2. Here's what happens:

I start the game and the FPS is ticking at about 47 on the 3GS in OpenGLES2.0. I have quite a lot on screen right now, so that is reasonable at this stage (I still have a few optimizations I can make too).

If you put a break in touchesBegan, it takes roughly 4-5 seconds before the break occurs and the game halts. This doesn't happen all of the time, and in fact, if you restart the app several times, it usually goes away. Moreover, if I let the game sit for a bit, it will eventually "sync." Like I said, the iPad 2 rarely exhibits the problem (one out of every 15-20 test runs), but it is definitely still present. If you perform a series of touches and accelerometer events in sequence, they are queued up and rendered just like you did them 4-5 seconds later. Very reminiscent of 4-5s lag delays back in the day online :)

I've tried a couple things like glFlush, or glFinish at the end of each render loop (doesn't seem to have any effect). Here's the top game loop:

- (void) drawView: (CADisplayLink*) displayLink
double dt = 0.0f; // Time in seconds since last loop
if (displayLink != nil) {
    dt = displayLink.timestamp - m_timestamp;
    m_timestamp = displayLink.timestamp;

// Update the game

// Render the game
[m_context presentRenderbuffer:GL_RENDERBUFFER];


The more I think about it... this could be a loading issue. Right now, I instantiate my main controller class for the game loop in the - (id) initWithFrame: (CGRect) frame call, which is also where I initialize OpenGL and (finally) call [displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode]. It's almost as if the renderer gets behind or ahead of the game logic and it takes it awhile to get caught back up.

From research, I could also just be throttling the CPU too hard. But if that were the case, I would imagine it wouldn't catch up... the FPS stays at a solid 44-46, and the input lag does go away if you let it sit for 10-15 seconds (with or without doing anything, it eventually catches up). I'm stumped, but I'll keep digging...


Doing some profiling... figured out that the accelerometer being polled 1/60 was a bit taxing. If I moved it to 1/30, this problem went away. This is concerning to me, as it likely suggests I do have a CPU overloading issue that will only be solved through some serious optimizations across the board (which is okay, I knew I had to do it anyway).

For anyone with a similar issue, especially if you are using the accelerometer, make sure you disable it if/when you aren't using it. I only use the accelerometer to allow the player to rotate/move the camera - so when the player has the camera locked, I am now toggling it off. This has solved my problem for now, but like I said, I probably only solved it temporarily. A real solution is going to take more work!

Hope this helps.


1 Answer 1


After more experimenting, I do believe this has to do with the accelerometer. Regardless of the in-game frame rate, I hit this input lag delay (touch and acceleration), but only when constantly polling the accelerometer. I'm using a lowpass filter on the info, but that should be unrelated. If you have a similar issue, try talking with the accelerometer at a reduced rate.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .