1

I am working on a game that essentially has two timers to control gameplay. One timer is a CADisplayLink that makes a call to redraw the display (with OpenGL) every frame, so slightly under 60 Hz. The other timer is an NSTimer that updates game logic, which I have tried running anywhere between 30 Hz and 100 Hz.

When I run the program in the iOS simulator, it is laggy and seems to be skipping frames. When I use Xcode to run the program on my phone, it works perfectly without any lag or skipping. When I then run the program from the icon on the home screen of my phone, it runs with lag.

What difference is there between loading the program on my phone and running it from Xcode and launching it from the phone itself? I understand that it is communicating with the Xcode debugger, but how could it work BETTER when connected to Xcode?

Lastly, there seems to be much less lag when I run both the game logic and the graphics from the same CADisplayLink. Could having both a display link and an NSTimer really be causing such problems?

Bart
  • 19,692
  • 7
  • 68
  • 77
pinerd314159
  • 534
  • 4
  • 10
  • 1
    Just a guess. You have a racing condition that force your application to stuck in synchronization block a lot. When you have debugger in play there is no racing case happens and no any issues with blocking of the code. – Nikita Leonov Aug 09 '11 at 01:05
  • Sorry, could you explain what you mean? What is a racing condition and what would cause the application to enter one? – pinerd314159 Aug 09 '11 at 01:11
  • If you have a multi-threaded code where several blocks accessing the same piece of code simultaneously then it may affect performance on a case when you have a synchronization between this blocks. When you start your app with debugger some of thread that cause synchronization cases may works slower and as result they may cause synchronization cases not so often. That will prevent other threads from blocking. But it is just a guess that can be done with limited info. I believe your case is a part of complex application so you are not able to provide a code piece for further analysis. – Nikita Leonov Aug 09 '11 at 01:19
  • I think Nikita's on to something here, because I've seen this exact behavior when dealing with a race condition in my code. That slight bit of different load placed on the system when debugging can be enough to trigger or prevent the collision between two different threads. – Brad Larson Aug 17 '11 at 17:29

0 Answers0