iOS What's The Best Technique For A Game "Mainloop"?

[kalimba]

Is it possible to have a "mainloop" in your iPhone application, such as what would be used in a game or other application requiring constant activity? If so, where is the best place to put such a loop?

I think most iPhone apps are designed to respond to events, do some processing, then return from the event handler. A game, on the other hand, obviously needs to be running the game code at all times. The old-school approach would have been to do something like this:

int main()
{
    init_the_game();
    bool running = 1;
    while (running)
    {
        running = run_the_game_loop();    // returns 0 if user quits game
    }
    cleanup();
    exit(0);
}

This is what I'd like to be able to do, but I'm sure where code like this can go without risking locking up the device or OS by "hanging" in a loop like this.

In the GLSprite demo, Apple chose to use an NSTimer to get updates at a regular interval, but I'd prefer to run the game code as quickly as possible and not be limited by a timer interval that is not optimally in sync with the game code.

 

[Stachelsk]

Is it possible to have a "mainloop" in your iPhone application, such as what would be used in a game or other application requiring constant activity? If so, where is the best place to put such a loop?

I think most iPhone apps are designed to respond to events, do some processing, then return from the event handler. A game, on the other hand, obviously needs to be running the game code at all times. The old-school approach would have been to do something like this:

int main()
{
    init_the_game();
    bool running = 1;
    while (running)
    {
        running = run_the_game_loop();    // returns 0 if user quits game
    }
    cleanup();
    exit(0);
}

This is what I'd like to be able to do, but I'm sure where code like this can go without risking locking up the device or OS by "hanging" in a loop like this.

In the GLSprite demo, Apple chose to use an NSTimer to get updates at a regular interval, but I'd prefer to run the game code as quickly as possible and not be limited by a timer interval that is not optimally in sync with the game code.

Optimize:
- Make the loop simpler
- If the loop wasn't made simpler, as least make (bool running) a constant... no need for it to be a variable.

int main()
{
    init_the_game();
    while (run_the_game_loop()); // will continue to loop as long as run_the_game_loop() does not return 0...
    cleanup();
    exit(0);
}

Should serve you well enough, based on what you said.

 

[jnic]

Honestly, use NSTimer, that's what it's there for. Otherwise you'll be mired in getting the game to be responsive enough; background threads seem to prefer not to yield quickly, and UI updates can only be performed from the main thread.

You can always run an NSTimer with an interval of zero if it bothers you.

 

[CommanderData]

I disagree with the NSTimer concept. It is ugly, and if your game world requires a lot of pre-processing per frame your app will be unresponsive to the user's input at times.

It is very easy to create an NSThread and put your gameloop within it. You still retrieve user input (touch or accelerometer) from the main thread. As the game loop updates the state of your "world", you can then draw the updated screen with performSelectorOnMainThread.

I started with the NSTimer approach on my first game and trashed it for the threaded model. It makes a big difference in the response time and feel of my game (which will be released later this month).

 

[jnic]

I disagree with the NSTimer concept. It is ugly, and if your game world requires a lot of pre-processing per frame your app will be unresponsive to the user's input at times.

It is very easy to create an NSThread and put your gameloop within it. You still retrieve user input (touch or accelerometer) from the main thread. As the game loop updates the state of your "world", you can then draw the updated screen with performSelectorOnMainThread.

I started with the NSTimer approach on my first game and trashed it for the threaded model. It makes a big difference in the response time and feel of my game (which will be released later this month).

Interesting; I found the opposite, though this was using NSTimer in a non-game app that required game-like updates/responsiveness (NSThread was noticeably less responsive in this instance).

I'd be interested for more opinions on this, would be good to see where each approach is more appropriate.

 

[CommanderData]

Interesting; I found the opposite, though this was using NSTimer in a non-game app that required game-like updates/responsiveness (NSThread was noticeably less responsive in this instance).

I'd be interested for more opinions on this, would be good to see where each approach is more appropriate.

I agree there may be situations where one way is better than the other, especially among different genres of games. I'd say anything with frequent action, lots of animation, or a lot of gameworld number crunching (simulations, etc) would proably be best served with running in another thread.

Also interested in hearing other opinions or specific cases where an NSTimer performed better or worse than an NSthread!

 

[Stachelsk]

I always saw NSThreads as being far more effective than NSTimers. In my opinion, NSTimers are used in introductory programs because they are simple to understand. When you start getting into threaded programming, there's a lot more to think about.