So, for people mostly interested in 3D-Gems, I did some shader-programming in this app.

We were able to scan our structured windows so I could get some 3D-Meshes of those. Then I had a look into OpenGL ES 2.0 Shader-Programming and the “refract(vec3, vec3, float)” function to calculate the refraction of the scanned surface.

Later I just had to set the iPhone’s Camera Video Images as the current background texture and the result looks like this:

And the corresponding undistorted picture (featuring my beautiful Hagström Super Swede )

If you guys are interested in the technical details I highly recommend PowerVR’s OpenGL programming SDK. They have some tutorials on how to program Shaders, and a C++-framework to import Blender-exports into your iOS project that were really helpful to me.

EDIT: Version 1.3 of iBeat fixes this, now it should work with all iOS Versions 3.1 to 4.3.

Please set up your UIViewController’s

"- (BOOL)shouldAutorotateToInterfaceOrientation:"

correctly, so you support both your Orientation and its UpsideDown-Version. Yes, it’s fine to just support Portrait or Landscape mode, but please support both directions!

You see UIInterfaceOrientation has 4 directions:

typedef enum {
UIInterfaceOrientationPortrait          = UIDeviceOrientationPortrait,
UIInterfaceOrientationPortraitUpsideDown = UIDeviceOrientationPortraitUpsideDown,
UIInterfaceOrientationLandscapeLeft      = UIDeviceOrientationLandscapeRight,
UIInterfaceOrientationLandscapeRight     = UIDeviceOrientationLandscapeLeft
} UIInterfaceOrientation;

Now I’m fine if you just want to support Portrait or Landscape and don’t wnat to resize everything between the two form-factors. Still for each direction there exist two entrys in this enum, and if you just do

(interfaceOrientation == UIDeviceOrientationPortrait)

you are just testing for one direction, not its variant turned around 180°. So please do the following instead:

UIInterfaceOrientationIsPortrait(interfaceOrientation);
//or
UIInterfaceOrientationIsLandscape(interfaceOrientation);

so finally your “shouldAutorotateToInterfaceOrientation” could look like this if you plan to show your App in Portrait Mode:

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation {
return UIInterfaceOrientationIsLandscape(interfaceOrientation);
}

This is not adding any extra work!

UIViews get rotated by 180° by UIKit, so allowing the user to turn the iPhone or iPad around can be achieved by changing one simple line per ViewController! There’s really no extra work in setting up all the frames because the formfactor stays the same, everything just turned upside down.

I understand this is completely obvious for all seasoned iOS Developers and was probably covered in depth on many times. Yet it still seems to happen in many Apps that I downloaded, so I thought I’d have to mention it.

This time I have an urgent problem, that I can only fix with your help!
Unfortunately the App iBeat seems to crash at the start on all iPads running iOS 3.2, while running perfectly fine on iPhones with iOS 3.1. (A friend has an old iPod I can use for testing)

I updated my own iPad to iOS 4.2 and since It isn’t possible to go back, I can’t test this problem on my own.
So If you have an iPad running iOS 3.2, please download (http://www.ibeat.us – its free) , start it, sync it with iTunes and finally send me the crashreport (ibeat@tactica.de). You may read about which folder the crashreports are in on your Computer here.

Thank you all in advance!

You can also see the new Interface-Element in the lower right, that always has the color of the active player!

Now I figured, I could render my game with 1 FPS as long as nothing happens, so I changed my code the following way:

• I start the game with a frameInterval of 60.
• Once I get a “touchesBegan” I go up to 2, that is 30FPS.
• Once I get a “touchesEnded”, I check whether there is any animation going on (the spinning arrows above a selected unit for example) or whether there is still another touch going on. This was pretty straight forward, since I store the points each finger started touching at in a CFDictionary, so I just needed to get its count and check if it’s zero. Then I set the frameInterval to 60 again
• My games main logic-class conforms to a “AnimationResponder” -protocol and the drawing classes store it as a “id<AnimationResponder> delegate”. So once an animation ended, I send this information to the main class and it throttles the FPS back to 1.

The result was so good, I could even feel a difference in the heat of my iPod!

Thank you Ed Welch!

Now I’m going to have a look at the GPU, specifically the advantages of using Vertex Buffer Objects on the new PowerVR SGX chip.

On the old iPod 2G I own, I tested GPU performance in this post and also confirmed that there was no performance advantage for using VBO’s.

Now the Analysis of my Engine on the SGX: (First without using VBO’s)

Whats interesting to note here is the appearent drop of FPS after I cross 35k triangles. I must have hit some bottleneck at this size of the matrix.

VBO’s:

Using Vertex Buffer Objects yields a huge performance increase, I am able to draw the same amount of triangles that used 15fps before at 30 fps!
So I doubled the fps for the appropriate map size!

Comparison of 2G vs 3G:

Now this performance increase obviously only happens, because my geometry array is static as long as the player doesn’t move a unit. But even this movement is just a discrete one-time update of the VBO and therefore doesn’t change user-feeling.

Here I’m gonna start to compare the interleaved-array fillrate using sequential loops vs. the performance of vectorized operations with vDSP. I did this for my iPod 2G in another post.

The Hardware:

The operation I want to compare is done by the CPU. On the iPod Touch 3G thats an ARM Cortex-A8 833Mhz (underclocked at 600Mhz). The iPod Touch 2G only had an ARM11 620Mhz(533Mhz) and in the WWDC Session 202 – The Accelerate framework for iPhone (available on iTunes for registered Developers) they said, the Cortex has superior vector-operation capabilities.

So let’s test them and see for ourselves

Again I’m putting 10000 scrub-geometries into the interleaved array, each consisting of 486 vertices. The code is pretty much the same as in the old post, except that I don’t move the normals around anymore.

I changed the normals  datatype to “short” to decrease the size of the interleaved array and they don’t really look worse if you don’t turn their normals. Therefore the times on the old iPod 2G changed a little so I’m going to test there again, too.

So the sequential code looks very straight-forward now:

for (int k=0; k<scrubVertexCount; k++) {
 _interleavedVerts[_vertexCount+k].v.x = xc + co*scrubX[k] - si*scrubY[k];
 _interleavedVerts[_vertexCount+k].v.y = yc + si*scrubX[k] + co*scrubY[k];
 }

The vDSP-Code was:

//tempVecX = co* x + xc;
vDSP_vsmsa(scrubX, 1, &co, &xc, tempVecX, 1, scrubVertexCount);
//tempVecY = si* x + yc;
vDSP_vsmsa(scrubX, 1, &si, &yc, tempVecY, 1, scrubVertexCount);
// x = -si*y + tempVecX
vDSP_vsma(scrubY, 1, &msi, tempVecX, 1, &_interleavedVerts[_vertexCount].v.x, stride, scrubVertexCount);
// y = co*y  + tempVecY
vDSP_vsma(scrubY, 1, &co, tempVecY, 1, &_interleavedVerts[_vertexCount].v.y, stride, scrubVertexCount);

Results:

So , what do we make of this data?

On 3G, the advantage of using vDSP stays roughly the same, at about 2.5 as before (Remember we had more complicated sequential code).

Things that spring to mind are:

• even though the ARM Cortex-A8 has only 77 more Mhz, for vector-operations it seems to be 5 times as fast. I suspect that some pipeline that gets the data to the processor from memory is bigger (or just more cache)
• the advantage of using vDSP is still about 2, so compared to the advantage on 2G we lost a little.

I also think that maybe the 3G runs a little code optimization of the sequential code, maybe even some vectorization of its own!

3D Engine Feature Outline:

I already explained my engine in this post. To recoup:
I have enabled :

• TexCoords
• Normals and GL_NORMALIZE
• COLOR_ARRAY
• VERTEX_ARRAY
• I draw using glDrawElements(GL_TRIANGLES,..) using an unsigned short array for the indices
• I issue a second draw command “glDrawArrays” for the UI, but switching this off doesn’t have any performance impact
• Antialiasing/Multisampling is switched on using an msaabuffer with a samplesize of 4

My interleaved Array has the following structure and a size of 26 bytes:

typedef struct _iVertex3D
{
    short uv[2];
    shortVert n; //just short[3]
    unsigned int color;
    Vertex3 v; //just float[3]
} iVertex3D;

Ideas I haven’t tried to improve performance:

• stripify all my geometrys and call glDraw(GL_TRIANGLES_STRIP,…) because then I’d have to add quite a lot of degenerate vertices to glue different parts of geometry together

Testing device:

Second Generation iPod Touch, that means MBX GPU and a ARM11 620 (533) Mhz CPU.

I tried painting using VBO’s but it didn’t change a single FPS, so I can confirm it doesn’t make a difference on MBX GPU’s!

FPS Results:

I tried different sizes of maps, that yielded different amount of vertices/triangles. I also added a column “triangles/second” to have a more stable metric of comparison against other devices/engines.

Please keep in mind I capped FPS at 30 to improve battery performance and omit unneccessary rendering!

So appearently the limit here is imposed by the triangles/second, that is the amount of triangles the MBX GPU running my 3D Engine is roughly at 440000.
That would also suggest I can draw up to 14600 triangles without loosing framerate, that is without the framerate falling below 30.

The samples he has on his homepage sound really promising, so now I’m looking forward to an awesome score.

Given I’ll also add some new animations to version 1.5, the media experience will have a whole new depth