by Rob Bajorek on May 20, 2009
Want to boost your iPhone OpenGL app’s framerate with one checkbox? It’s easy; turn off Thumb instructions.
What are Thumb instructions?
The iPhone uses the ARM 1176JZ processor, and Thumb instructions are 16-bit versions of common 32-bit ARM instructions. By default, your Xcode project will compile with Thumb instructions.
Why use Thumb instructions?
On embedded systems like the iPhone (or any system, really, but here especially), you have to think about the space your app uses. Smaller instructions mean smaller code in memory and on disk. That’s a good thing! However, there’s a trade-off: performance.
According to Apple, the cost comes from floating-point operations. Ripping out the GLfloats from your app isn’t the way to go, so let’s learn a better way.
How do I turn off Thumb instructions?
Here’s what to do in Xcode:
- Open your project
- Choose Project -> Edit Project Settings
- In the Project Info window, choose the Build tab
- In the search box, type “thumb“
- You should see a “Compile for Thumb” setting. Uncheck it. (Click image to enlarge.)
- Clean and rebuild your project.
That’s it! If you don’t have the setting, make sure the Active SDK is set to Device. The setting isn’t applicable to the Simulator.
What kind of frame rate boost will I see?
I had improvements of around 20, 30, and 50%. Hopefully you will see even bigger ones!
by Rob Bajorek on May 9, 2009
[Update 2009/06/04: Version 2.0.1 released. Bug fix release, see here for more information.]
It’s ready! The promised Cheetah3D -> iPhone header converter is right here:
With this program you can convert exported Cheetah3D OpenGL .h files to an iPhone-compatible format.
Please read the comments at the top of the program file for usage information. I tested this on Mac OS X 10.5.6, but it should work on any system with Perl 5. I purposely did not use any external modules (no messing with CPAN here.)
The software is free, licensed under GPL 3. If you try it, please send feedback or respond in the comments. Thanks!
by Rob Bajorek on May 8, 2009
Bad things can happen when you don’t understand what you’re doing.
When writing my first iPhone application in Objective-C, I banged my head against the wall of memory management. EXC_BAD_ACCESS became a frequent and unwelcome guest during testing.
I have a C/C++ background, so picking up Objective-C was not particularly difficult. However, Objective-C objects are a different beast than I was used to. I soon noticed a theme while debugging my app; crashes happened around the words release and dealloc a lot.
I started sprinkling retains throughout my code, hoping to ward off the memory errors. Sometimes it worked, sometimes I created a leak, and sometimes the crash jumped somewhere else. It was like playing whack-a-mole. Bash a bug in one place, and it popped up in another.
The problem was, to me, Objective-C memory management was something magical. I created and deleted objects all the time, and usually it worked. But, I didn’t know the rules for when to retain. I was trusting the object fairies to know what I wanted to keep and what to whisk away.
Eventually, I stopped and said “There is something fundamental that I’m missing.” I spent an hour reading Apple’s Memory Management Programming Guide for Cocoa. It was like flipping on a switch in my head. I went back to my code, ripped out the useless retains, then picked off the bugs one by one.
Magical thinking is a recipe for disaster. You need to understand the tools you use. If something is a black box to you, take a crowbar and rip it open.
Don’t trust the fairies. They don’t take the support calls from your frustrated customers. Learn the magic yourself.
by Rob Bajorek on May 7, 2009
After starting down the road of OpenGL development on the iPhone, I knew I needed a 3D modeling application to do anything fancier than spheres and cubes. My first try at an application was Blender. Blender has a lot of fans, but it’s also quite complicated. Just going through the tutorials was a chore. I didn’t want to learn how to draw fancy shapes like monkeys; simple polygons were sufficient.
After getting some basic models together in Blender, I had difficulty exporting into a usable format for the iPhone. The Wavefront OBJ format is the generic 3D model standard, and there is an importer for iPhone out there. It’s not feature complete, and doesn’t support UV texture mapping at this time. That’s a big hole for my purposes.
I played with Blender for a couple of days, but I struggled getting textured Blender objects into my iPhone project. Other people do it, so I’m sure it’s my lack of knowledge in that field. However, I don’t plan on being a 3d modeler; I’m the software architect. I need to spend my time on my area of expertise. But my needs were simple (mostly basic textured polygons), so I still preferred to do it myself.
What did I do? I ended up buying Cheetah3D, made my shapes quickly (and easily!), and exported it to a .h file in under 15 minutes. Now that’s what was looking for from Blender!
All done? Close, but not quite. Cheetah3D’s .h export feature makes an OpenGL-compatible file, not an OpenGL ES one. But, it took under an hour to hammer out a Perl program to convert the header file into an iPhone-usable one. Now I just run my Perl program over Cheetah’s exports and *poof*! Add the new header file to my iPhone project, import it at the appropriate place, and it Just Works.
End result? Cheetah3D is doing everything I need in a 3D tool. Not to say that Blender is a bad program. Far from it; it has an enormous amount of power and it’s free. But just like you won’t recommend Photoshop to get rid of red-eye, for my basic needs Cheetah3D does the job.
I have some requests for my Perl program, so as soon as I clean it up I’ll put it out for you to use.
[Update 2009/05/09] The Cheetah3D -> iPhone header converter has been posted.
by Rob Bajorek on May 6, 2009
This post is about my start at OpenGL programming on the iPhone.
I have an iPhone project that needs animation. After considering using 2D vs. 3D objects, OpenGL looked like the best option. Once I made that decision, I needed to start learning OpenGL. And how did that go? Let’s just say learning OpenGL is a non-trivial exercise.
First stop, the Apple Docs
The natural place to start learning OpenGl for iPhone is Apple. The iPhone Developer site has a lot of information about iPhone programming. In particular, the iPhone Application Programming Guide has a section on OpenGL ES. The information starts with setting up a drawing context and view for OpenGL. There are a number of suggestions, lists of supported features, and comparisons between the simulator and the device. But, it doesn’t really talk about programming in OpenGL. In short, it’s a great list of tips, but it assumes you already know what you’re doing. Surely I’ll come back to this page, but it’s not the place to start.
Apple did include some links, though. That’s where I went next.
OpenGL ES, the standard
I said before that iPhone OpenGL is not the full spec. It’s a special system designed for embedded devices and consoles called OpenGL ES, specifically version 1.1. The keepers of the standard are the Khronos Group.
The main document that I used from Khronos was the OpenGL ES 1.1.12 Full Specification (PDF). This document describes the specification, although the target audience is the OpenGL ES implementor, not the application programmer. Still, I picked up core concepts like matrix modes and building polygons. I couldn’t actually do anything with that knowledge since it didn’t tell me how to build an app.
At this point, I decided to ask Google.
The Red Book
I looked through some forums and tutorials, and the suggestion I tried next was to learn from the “official” guide to OpenGL, AKA the Red Book. By far, the official guide was the best introduction I found to OpenGL. This guide is an actual introduction, teaching you how to program from scratch.
This reminds me of an important point; OpenGL is a C API, not an Objective-C one. No classes or methods here. It’s globals and functions. There’s not much difference, but it may confuse you a bit if you started with Objective-C.
After digging into this book, I started to understand how OpenGL works and I could actually write code! It didn’t translate one-to-one to the iPhone because this is an OpenGL book, not an OpenGL ES one. However, it wasn’t difficult to apply the book to the iPhone. If I did get stuck, someone else did too and I found an answer from Google.
Also, Apple’s OpenGL ES examples made more sense. I started with those and built on them while going through the Red Book.
The Recommendation
I feel comfortable with OpenGL ES now. In fact, I already have a working 3D app integrated with the Bullet Physics library (a topic for another day.) My recommendation if you’re starting from scratch is to use the Red Book and the OpenGL examples from Apple. Play with the example projects until you feel comfortable, then go from there.
