Note that there are some explanatory texts on larger screens.

plurals
  1. POiOS Games and Run-Loop Management
    text
    copied!<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>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload