Alternative to NSTimer

When using a while loop to handle the main game loop, is your game able to handle multiple touches? I switched from NSTimer to a while loop similar to demonpants' but my app no longer handles multiple touch events. It won't recognize new touch events unless any previous touch event has ended.

When you create an instance of a NSRunLoop, it creates an autorelease pool. Any methods/functions/whatevers that get called by this NSRunLoop have an autorelease pool to back it up.

A CFRunLoop does not create an autorelease pool. If a CFRunLoop calls a method/function/whatever, it is not backed up by an autorelease pool. For example, when you create a CFStream with a callback for when bytes arrive, that callback function does not have an autorelease pool.

You might think you can avoid this problem by not using autorelease. This is ridiculous. Just because you don't explicitly send an autorelease message to one of the objects you own doesn't mean that a method you call doesn't send the message autorelease to one of the objects it owns.

My 2 cents... I'm working on a game that's become quite large in scope now. It's in Objective C as much as possible but since we had to port from Windows some of the engines, there are many areas that are Objective-C++. It's mixing 2D and 3D graphics in OpenGL ES and has audio, accelerometer, touch, tap, and the kitchen sink. I've been using NSTimer for the game loop at 1/60 ever since the beginning and mach timers for timing and it runs great.

From experience I recommend strongly that you keep NSTimer for your loop and use mach for timing. If you even get more than 60 FPS, your game is pretty simple and it shouldn't matter anyway. If it's less than 60 FPS NSTimer will fire as frequently as possible anyway. Trying to do all this other stuff is complicating things for you and might make your life miserable.

Apple is a very successful company and they have some of the most intelligent and innovative people in the world working for them. If you find yourself cussing them as you struggle to defy their design, maybe consider that you're doing something wrong, not they.

bmantzey Wrote:My 2 cents... I'm working on a game that's become quite large in scope now. It's in Objective C as much as possible but since we had to port from Windows some of the engines, there are many areas that are Objective-C++. It's mixing 2D and 3D graphics in OpenGL ES and has audio, accelerometer, touch, tap, and the kitchen sink. I've been using NSTimer for the game loop at 1/60 ever since the beginning and mach timers for timing and it runs great.

From experience I recommend strongly that you keep NSTimer for your loop and use mach for timing. If you even get more than 60 FPS, your game is pretty simple and it shouldn't matter anyway. If it's less than 60 FPS NSTimer will fire as frequently as possible anyway. Trying to do all this other stuff is complicating things for you and might make your life miserable.

Apple is a very successful company and they have some of the most intelligent and innovative people in the world working for them. If you find yourself cussing them as you struggle to defy their design, maybe consider that you're doing something wrong, not they.

Oh they are wrong often enough ... like for instance their borked implementation of OpenGL driver (copyVertexData anyone ?) ... implicitly disabling anti-aliasing by forcing OpenGL ES devs to render to a texture etc ..etc ..

NSTimer is kind of like WM_TIMER on Windows â€¦. good enough for GUI apps but I donâ€™t know anybody who uses it for coding time sensitive apps ( like games)

I'm going to disagree with the general sentiment in this thread and say using a thread is much better than using a timer. If the amount of time it takes to render your frame gets too close to your timer period (16.667ms for 60fps), then the incidence of misfires from the timer becomes unacceptable. I posted a blog about this earlier today (although I wrote this up a few months ago).

A timer overrun, no matter how small will mean a 'tick' is missed. The next tick will be at the next scheduled time. It's quite common to see ticks like this:

16.67ms, 16.67ms, 33.34ms, 16.67ms, etc.

That 33.34ms tick is generally going to cause a jitter. Sure, increasing the timer period as many here have suggested helps. But a misfire still means waiting for the next scheduled tick. A thread will never have this problem.

In fact, if your thread churns out frames as fast as possible, you'll find if your rendering takes less than 16.67ms your framerate will be exactly 60fps as one of the calls (I suspect flipping the frame buffer) blocks.

So in my book, a thread is the only option unless you can render your frame in something significantly less than 16.67ms (for 60fps).

mpatric Wrote:I'm going to disagree with the general sentiment in this thread, and say using a thread is much better than using a timer.

Generally this thread dedicated exactly to unacceptable behavior of NSTimer. I have found this thread when i have got suddenly doubled render time. i was trying to setup fixed time step game loop with dt = 0.030s, and found that actually it takes 0.060s.
As you can see my post above there is no NSTimer atall, and no mess with threads. Only odd thing is I have very unstable render time that jumps from 42ms to 55ms from frame to frame, and i cannot find reason of it.

PS I can only confirm that render in thread could increase render performance in some cases.

mpatric Wrote:I'm going to disagree with the general sentiment in this thread and say using a thread is much better than using a timer. If the amount of time it takes to render your frame gets too close to your timer period (16.667ms for 60fps), then the incidence of misfires from the timer becomes unacceptable. I posted a blog about this earlier today (although I wrote this up a few months ago).

A timer overrun, no matter how small will mean a 'tick' is missed. The next tick will be at the next scheduled time. It's quite common to see ticks like this:

16.67ms, 16.67ms, 33.34ms, 16.67ms, etc.

That 33.34ms tick is generally going to cause a jitter. Sure, increasing the timer period as many here have suggested helps. But a misfire still means waiting for the next scheduled tick. A thread will never have this problem.

In fact, if your thread churns out frames as fast as possible, you'll find if your rendering takes less than 16.67ms your framerate will be exactly 60fps as one of the calls (I suspect flipping the frame buffer) blocks.

So in my book, a thread is the only option unless you can render your frame in something significantly less than 16.67ms (for 60fps).

Yeah, it makes sense.

On other hand I am kind of puzzled why would you need a separate thread to handle timing issues.
Imo it is much simpler to run your own loop and simply enter the default message loop if you have some time to spare or just for a set bare minimum if your game starts to chase its own tail.

I think people are misunderstanding NSTimer. It's not a hard-realtime timing solution. You're supposed to set the timer to fire faster than your intended framerate, and check the time in your callback. If it's running too fast, you'd just do nothing, and wait for the next callback. If the timer runs slower than intended, it's because device is busy doing something else.

The custom runloop doesn't do much else, only in a roundabout fashion. A separate thread only helps if the main thread is blocked on IO or other transactions which leave the CPU idle.