I found it useful to change some of the warnings generated by Visual Studio.

For instance, this statement:

if (num = 10) { doSomething(); }

Generates a warning, but I cannot see any case where this would not be a bug. So I change this warning and some others to errors: like this:


#pragma warning (error: 4715)
#pragma warning (error: 4706)
#pragma warning (error: 4553)    // '==' : operator has no effect; did you intend '='?
#pragma warning (error: 4150)    // deletion of pointer to incomplete type
#pragma warning (error: 4390)    // empty controlled statement found;
#pragma warning (disable: 4996)  // openf is dangerous (not!)


Now, there’s no way you can ignore it. By the way, there is a bug in Visual Studio, sometimes it won’t flag warning mentioned above at all.

The documentation for the iphone’s VFP processor says that all floating point instructions take 1 cycle, apart from divide and square root, which take 15 cycles.

This leads to a very obvious optimisation, to cache your divide operations.

In other words if you have code like this:

float fl = 1.0007f;
for (i = 0; i < 16; i++)
matrix.Set(i, matrix[i]/fl);

you can increase performance by doing the divide outside the loop:

float fl = 1.0f/1.0007f;
for (i = 0; i < 16; i++)
matrix.Set(i, matrix[i]*fl);

I measured this and found that it does indeed make a big improvement.

Also, I thought it would be interesting to try out the old Quake inverse square root trick.

float InvSqrt(float x){
   float xhalf = 0.5f * x;
   int i = *(int*)&x; // store floating-point bits in integer
   i = 0x5f3759d5 - (i >> 1); // initial guess for Newton's method
   x = *(float*)&i; // convert new bits into float
   x = x*(1.5f - xhalf*x*x); // One round of Newton's method
   return x;
}

This code works on the iPhone, but the results are less accurate.

float fl = 2.0f;
result = 1.f / sqrt ( fl );   // gives 0.707106769
result = InvSqrt(fl);   // gives 0.706930041

the actual value should be 0.70710678

I measured the performance and found that it’s a touch faster, but not much.

Full screen anti-aliasing is a feature that greatly improves the graphic quality of any game and is supported by the powervr chip. Unfortunately, you don’t have access to the feature, because the iPhone does not use EGL. Instead it uses the framebuffer extension to bind to a surface and in order to enable anti-aliasing you have to call eglChooseConfig with the EGL_SAMPLE_BUFFERS parameter and this is not possible.

Funnily, enough I found a project that appears to use EGL with the iPhone: http://code.google.com/p/iphone-dj/

However, looking a bit close I see that the egl.h file does not even exist in the SDK, so the code in that project should not even compile (pretty wierd that).

This also means that the pbuffer isn’t supported, as that is enabled via eglChooseConfig as well. And to top this off I also heard that the GL_IMG_vertex_program extension is disabled (I think this prevents you from using bump mapping and cartoon rendering – as demoed in the powervr sdk)

Edit:

I reciently discovered that there exists an unofficial iPhone SDK, which includes egl. This is probably what iphone-dj was using. So, you probably can get anti-aliasing working if you don’t mind using an unofficial SDK.

I was having problems rending low polygon trees in my scene. It was because they used transparent textures which are always problemic. I found this artical that helped me greatly:

http://www.sjbaker.org/steve/omniv/alpha_sorting.html

The solution was to render all opaque objects first, then do:

glAlphaFunc(GL_GREATER, 0.1f);
glEnable(GL_ALPHA_TEST);
and now every thing renders perfectly

Origonally I thought XCode was pretty good, indeed it does do somethings better than Visual Studio. However, the support for c++ is lacking, especially if you use templates. XCode can’t display template variables in the debugger window, nor does “Intelisense” work. One of my  projects has a tonne of template based classes, so that’s what pushed me to see if I could do the work on Windows instead.

The PowerVR SDK comes with a Windows OpenGL ES emulator. It didn’t take me long to get my code working with that, because all my code is portable: c++, stl and OpenGL. Straightaway my productivity doubled. So, now I do the implementation and debugging on Visual Studio and periodically switch to Mac to make device builds.

I did some more work on my engine.

Implemented redundant node removal and made the class hierarchy more logical and added compressed textures.

The result was that I reduced the frame time to 53ms from 63ms (presume that’s mainly because of reduced nodes)

Also discovered, that just by building on Mac that my character’s face renders correctly (I could have sworn that it wasn’t like that on Windows)

At first it looks good… but (like most things) when you get into the details, you realize there are some klunky bits. So, I was just looking how to open a png file and it’s dead easy and you can do all sorts of sophisticated transformations, but if – for any reason, you need a simple pointer to the pixel data – you’re boned. It requires you to go around in hoops. And to load a texture you need the pixel data. So, how does Apple do it in their examples? Have a look:

http://read.pudn.com/downloads120/sourcecode/macos/510268/CrashLanding/Classes/Texture2D.m__.htm

yep, they’re pretty much forced to go around in hoops themselves. This must be some pretty inefficient code, though because you have to copy the data twice, once from the file, then from the UIImage to some sort of wierd memory bitmap and then uploading with glTexImage2D.

I already have a tga class, so I’ll just store my images as tga for the time being. It looks like it’ll work a lot better than using the cocoa classes.

Anyways, In the final game I should use powervr compressed images. I have to look into that more, but I assume the data is just dumped into glTexImage2D as it’s read from the file. Powervr compressed images are a dark art. They can only be created via a windows tool and can’t be displayed in the emulator. Quite, ironic that Apple says in their guidlines  “use PVRTC”, and yet there’s no mac tool to create it.

Arrgh. Finally got it working. The whole problem was because my c++ class was a member of an objective c class and objective c clases don’t call constructors. Next stop is to try out a skinned mesh.

So far, xcode looks really nice. It uses gcc and gdb, however it still manages to be user friendly. The debugger doesn’t handle stl properly by default, but it can be customised.

Right click variable and select “edit summary format”, then whatever you paste in their will be stored and remebered for all variable of same type. For instance, this is for stl:string:

size={(int)$VAR.size()} “{(char *)$VAR.c_str()}:s”

After spending ages trying to get stlport to compile, I found that the stl was already in the iPhone SDK… but why does it complain “file not found” when you #include string? For some reason all the .m files have to be renamed .mm (even though I was using stl from a .cpp file), otherwise it pretends that stl does not exist.

Mac development for Windows coders is simply horrible. Everything is different and the worse thing by far is the keyboard. Apparently, Spanish Mac keyboards are totally different to Spanish Windows keyboards… apart from all the usual differences, the key that the angle bracket is on is non-existant, the windows key is used instead of the Alt-gr key… except for some characters like the tilda, which is with the ñ key.