Game Loops in Cocoa

[Nick]

Are game loops not used when in Cocoa? Such loops similar to while(!done)? I'm making a game just using NSButtons and NSTextFields and am not sure how to get the game to cycle through a series of events and checks as a loop. The game is similar to Whack a Mole except I'm using buttons to achieve the effect. I am also thinking of using the text fields to help dictate the specific button. Any ideas? I actually tried a while(!done) loop and the game froze and I had to force quit.

[AnotherJake]

You're really not supposed to circumvent the event loop in Cocoa except when running full screen. The proper way to do a "game loop" in Cocoa is to set up an NSTimer and have it call your game code repeatedly.

[DoG]

You would not have a polling loop, but rather install a timer to fire the idle function at certain intervals (say 1/200th of a second). You should get events the usual way, by waiting for one of the event handlers and delegates to be called in your view or window controller.

[AnotherJake]

Here's a short example of how to use a timer:
//---------------------------------------------------------------------------
- (void)myGameInit
{
NSTimer *timer = [[NSTimer scheduledTimerWithTimeInterval:0.001f
target:self
selector:@selector( myGameLoop )
userInfo:nil
repeats:YES]
retain];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSEventTrackingRunLoopMode];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSModalPanelRunLoopMode];
}

// this gets called repeatedly by the system automatically
//---------------------------------------------------------------------------
- (void)myGameLoop
{
// do game stuff here
}

[Nick]

Thanks a lot.

[Taxxodium]

If you want a while(!done) type of loop, you can add an NSThread. Although I don't recommend it because your code will look ugly.

Just go with the timer and you'll be fine.

[Nick]

When using this kind of timer, why fire at a rate faster than the screen can refresh?

[AnotherJake]

There really isn't much point to it. You can have the timer fire as often as you wish. With my stuff I don't really care about wasting cycles most of the time and just let it rip. If I'm using OpenGL I'll still let it go as fast as it can during development to alert me to any stupid coding moves that might drop cycles dramatically. For deployment I turn on vbl synching. I don't think it really matters that much but if it bugs you, just turn it down!

[Nick]

Ok thanks.

[DoG]

When using this kind of timer, why fire at a rate faster than the screen can refresh?
Don't forget that this is still just a single thread, so in short your timer will only fire that fast if nothing else is taking up CPU time. Usually, though, you do something in your idle loop which will fill the void. Setting the timer at a very low interval is just so that you get minimal UI lag whenever possible.

[nabobnick]

http://developer.apple.com/samplecode/glut/listing67.html

This shows an "official" way to have a loop in Cocoa. I use a slightly modified version in my app.

[nabobnick]

As I've been meaning to do for a while I have started to go through my code and clean it up for general consumption. I've created a new project and have the basic code with two classes that overrides the NSApplication run method and provides a run loop similar to what is described in PC game programming books. It is also the technique used by Apple to implement their version of GLUT (as per my prior post).

The new code I have is as clean and concise as I could make it and since it currently only consists of a small set of functionality it should serve as a good starting point for anyone interested. Feel free to use the code verbatim or hack it up for your own purposes. Also I do not care if you strip the top comments out.

CocoaGameEngine (http://www.nutzy.net/CocoaGameEngine_01.tar.gz)

Also if you have any suggestions to improve it or find any problems with it let me know and I'll add them in.

[nabobnick]

Here is the next iteration of code (http://www.nutzy.net/CocoaGameEngine_02.tar.gz) which includes variable rate rendering and fixed rate game logic, I also put in limits for event processing to keep events from slowing down the loop too much. Until I get some rendering and logic code to try it out on its a bit theoretical how it will perform, but it's based off some code I found on flipCode and the ideas seemed sound.

[codemattic]

Hey - thanks for posting these. Im currently using NSTimer but want to move to a game loop from a NSApp subclass - so this is good. Seeing it fleshed out step-by-step is helpful. Arrekksu's 'Shoot Things' code has some pretty extensive NSApp set-up and event-loop also.

[nabobnick]

Part 3 (http://www.nutzy.net/CocoaGameEngine_03.tar.gz)

Includes a cleaned up and reworked version of my Cocoa wrapper for Quartz Services calls. (Press CMD-Q to exit). Improvements from my prior version in other code I've release include adding the DisplayManager class, improved memory management (if I've messed up any release, autorelease, etc calls let me know), more functions supported, better object-orientedness, an all around just cleaner code.

Although some people think it's a waste I think it makes the code easier to read (none of those long C function names), groups the functionality so it's easier to remember, and any speed decrease it makes is not important since you call these functions usually only during game initialization and not every game loop iteration.