title: iOS Games and Run-Loop Management
body: <p>First, my question: How do you manage your iOS Run-Loop?</p>
  
  <p>Next my reason: I've been researching this with a variety of prototypes (v. early stage development) and have found a number of perplexing issues.</p>
  
  <ul>
  <li>First, input issues and the run loop lead me to try the following:
  
  <ul>
  <li>when using the most recommended system (CADisplayLink) I noted that certain touch inputs are dropped once the CPU load causes the buffer flip (presentRenderBuffer) to have to wait a frame. This occurs only on the device and not in the simulator (annoyingly - this seems to be related to wait for vsync blocking on the main thread &amp; the way the app run-loop process touch input &amp; eats messages)</li>
  <li>when using the next most recommended system (NSTimer) I noted that certain touch inputs are dropped once the CPU load reaches a certain point in the simulator but not in the device (also annoyingly). NSTimer also results in much lower precision on when my updates fire</li>
  <li>when using the least recommended system (running the run loop in it's own thread managed internally with a high-precision timer built from mach_absolute_time, all my touch input problems go away, however my ASSERT code now traps in the wrong thread and only if I usleep following the software interrupt. (My assert code is similar to <a href="http://iphone.m20.nl/wp/?p=1" rel="noreferrer">http://iphone.m20.nl/wp/?p=1</a>) I really like having my assert code trap immediately at the line that caused the problem, so this solution is not really workable for me: harder to debug.</li>
  </ul></li>
  <li>Second, lost time:
  
  <ul>
  <li>while investigating the system, I found that regardless of framerate (bizarrely, but I suppose statistically it still makes sense w/vsync) I'm waiting approximately 22% of the time on the vsync. I've confirmed this by moving around glFlush/glFinish and by playing with how often I do the presentRenderBuffer calls. This is key time that I'd love to be processing AI, etc rather than simply stalling on a blocking gl call. The only way I can think of around this would involve moving rendering into it's own thread, but I'm not sure if it's warranted to start re-architecting for multi-threading on a single-processor device.</li>
  </ul></li>
  </ul>
  
  <p>So has anyone found a magic bullet around these issues? Does anyone have a killer run-loop architecture that's kick-ass on this platform? At the moment it looks like I have to pick the lesser of the evils.</p>