I have an iOS OpenGL ES 2.0 game and currently have a CADisplayLink with a :render method. In this render method I do all the game's logic updates and drawing.

Is this correct? Or should my game logic go somewhere else - and if it should go elsewhere... where?

The reason I'm asking is that I've been writing a game and it's starting to exhibit strange behaviour which I suspect is related to the game logic taking longer than a frame to compute, and after following a few different 'fix your timestep'/framerate independent drawing type posts I can't quite match it to how iOS handles things since in iOS there isn't a 'main' style loop.


2 Answers 2


Calling game and update logic when CADisplayLink fires is the correct way of doing things on iOS. Have you profiled your game to see what is taking a long time and interfering with a smooth frame rate?

A nice way of keeping logic updates smooth and decoupled from rendering on iOS is to handle updates when CADisplayLink is called then signal another thread to render and swap the framebuffer. This does introduce some synchronization headaches and issues with OpenGL contexts on different threads, but it's worth investing time in.

The iPhone Doom port uses this sort of solution. There's a good code review here: http://fabiensanglard.net/doomIphone/index.php

Note, iPhone Doom uses an NSTimer, but the principle is the same for updates with CADisplayLink.


I think you can find your answer by checking out the cocos2d-iphone sdk. It uses both OpenGL ES 2.0 and CADisplayLink also its written very well so you might as well us it if you are making a 2D game.

If u are looking for 3D game or application then cocos3d is good.


You must log in to answer this question.

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