Xcode 4 OpenGL Game Template Question

I'm embarking on my next iOS game and I've upgraded to Xcode 4 and have used the "OpenGL Game Template"as a basic starting point.

I really like the new GLKit framework introduced with iOS 5. But, one question I have is it "appropriate" to use the update function in the ViewController as a place to update game logic (I.E. everything BUT sending commands to the GPU)?

In past projects I've used an NSTimer or CADisplayLink. But, is the supplied update function the new preferred way of doing things in iOS 5? Or, am I totally off base?

Yes, the update function is where you are supposed to put the logic. The GLKViewController creates a CADisplayLink for you. The idea behind separating out the update and drawing logic is so that it doesn't require you to draw every frame that update is called for (something I don't think it actually does though), and so that it can draw a frame without needing to call update such as when your view is resized and must be redrawn.

One bad thing about GLKit that I found was that forces you to run your drawing on the main thread. This is bad because one you start using a lot of CPU time to run the game, iOS will start buffering your touch input for 0.5 to 10 seconds. The only workaround at that point is to use less CPU time or drop the framerate to 30 or 20 fps. I started out using GLKit in the new Chipmunk showcase app I made to try it out, but eventually removed it because of this.

GLKit is great simple API for simple games that don't use a lot of CPU, but it was definitely not designed to be scaled up.

Thank you for the information Skorche. I did notice yesterday that update does seem to be called synchronously with the draw function as if they are on the same thread.

Would you recommend spawning another tread to run all the game logic on? Is there anything wrong with keeping the rendering on the main thread? I could be wrong about this but I thought I read somewhere all calls to OpenGL had to be on the main thread? Or, the thread the context is created on?

Yeah it does appear as though it always calls draw immediately after calling update. It has a lot of timing values it gives you like time since last draw/update, but they always seem to return identical values.

Multithreading: You could put the update on a second thread. Generally the rendering is more expensive and a better candidate for putting on a separate thread though.

You can use a GL context on any thread you want, but it's not thread safe. In other words, use it from only one thread at a time either by using locks (hard and error prone) or ensure that all of the GL commands are run exclusively from a single thread (much easier, especially if you use GCD). If you put your rendering on a secondary thread, make sure you handle the resizing and teardown on the render thread as well.

If you want an example of something that worked well for threading you can take a look at the Chipmunk showcase app: https://github.com/slembcke/ChipmunkShowcase Particularly the GLView and ViewController classes. It still generates the vertex array on the main thread to avoid syncronization issues, but the rendering thread uploads it to the VBO and and makes the draw call. If you had a more complicated rendering needs it might be easier to run the update and render together on a separate thread and pass the input from the main thread.

Anyway, I don't really know of a simple, foolproof, beginner friendly way to split things into separate threads. You really have to pass some sort of immutable render-state from the update loop to the renderer so you aren't reading directly from values that might be changing in the update loop. My solution was to make a single big geometry buffer be that render state because it was easy to do that way.

Ok, thanks again for the helpful insight. I have a few ideas floating around on how I will make my rendering run asynchronous to my game logic. And, now I have a much better understanding of how GLKit operates.

The Chipmunk Showcase is also very helpful. On another note, I checked out Twilight Golf, very impressive and fun!