Comments from the 'Dev'
Blog
Multitasking Escapade
Put in changes to make Sea Assault and Ant Planet work better with multitasking. So, the games should pause in the background properly. If OpenGL is used in the background, then the game content might have to be reloaded into the context when you bring the app to the foreground -- the OS will terminate the app if it finds out your using OpenGL. Since I enabled multisampling, the programs are linked against the iOS 4 sdk. Just pause in the background. Same code for handling incoming calls too while playing.
The second generation iPod and the 3G phone do not have multitasking in iOS 4. On that hardware its like the old iOS 3 behavior.
Submitted the fixes to iTunes Connect.
Also, I notice if you have developer logging turned on, the logging can cause animation hiccups while playing. I figure most people will not have that enabled.
Sort of a pain to debug the iPod with iOS 4.0. For some reason, if you type in your wireless network password it will not accept the shift key! All lower case! But looks like iOS 4.01 handles this properly. iTunes currently does not update iOS to 4.01 for iPods -- think the main purpose of this was to fix the phone reliability issues. The only way around it was to use the iPhone Configuration Utility with network settings.
More multisample improvements...
I added the multisample iOS 4 improvements to Ant Planet. Looks much cleaner now.
It makes quite a difference with the ant legs and the trunks of the palms. Initially, I modeled the truck with more rounded edges to help when multisample was disabled.
Tweaked some of the physics collision response code too. So, debris bouncing should be better.



Multisampling iPhone iOS 4
Today, Sea Assault has become multisampled ! That is, the game has better anti aliased edges.
On a typical pc, this would be fairly easy. You just enable multisample with glEnable. But on the iDevice, you have to set up an additional frame buffer object and use the OpenGL ES extension GL_APPLE_framebuffer_multisample.
There are some annoying issues in both Sea Assault and Ant Planet that can be remedied by multisampling. In Sea Assault, the helicopter blades appeared too pixelated and the edges of the landing pad appeared jagged. In Ant Planet, the ant legs appear pixelated too.
All devices running iOS 4 and with newer hardware than the 3G should support multisampling. As far as iPod is concerned, that would be the high end iPod 3rd generation too. Unfortunately, this feature is not implemented in iOS 3 on all hardware. With the change, I made sure the games will still be compatible with older versions of iOS.
Here are some screen shots. I put red arrows in the picture to illustrate the improvement.
No multisampling:


Here are some screenshots with multisampling turned on and samples set to 4 :


I made multisample a preference option too. Surprisingly, its still quite fast on the 3GS iPhone and iPod Touch 3rd generation.
So, should be a Sea Assault update soon after some more testing. And then Ant Planet....
Maintenance Updates
I submitted another update last night for Sea Assault and Ant Planet -- making sure they work in the new iOS 4 GM. I found a memory dealloc error which caused Sea Assault to crash on start up in iOS 4 GM. Ant Planet was not crashing yet had the same bug. Astroidica does not have this memory issue.
Typically, I wait till the last gm build to do these checks because I get afraid that I might brick my device with beta software. This approach worked well when 3.0 was released.
So, expect another round of updates for Sea Assault and Ant Planet. Usually, I wait a couple weeks at least between updates but this is an important fix. It would not surprise me, if it created an issue with iPad too.
Universal Apps
Downloaded the newest official XCode tools. The new tools include iPad support. I tend to avoid beta releases of developer tools.
Seems real easy to convert the app to a universal app -- an app that runs on iPod/iPhone/iPad. Basically, control click on your target and then update it for iPad. XCode creates a different xib file for each device and changes project settings automatically. It does give an option to create separate binaries. Now you can create completely different layouts with interface builder for each device which is sort of cool. The app must run on os 3.0 or greater.
There are some info plist settings that need to be added. For instance, supported interface orientations. All orientations need to be supported on iPad and I'll have to review that. There are different icons that can be added beyond the typical 57x57 icon on the iPad. After converting my latest app I've been working on to universal, I created one of the default applications that XCode creates and compared it.
Some minor things I've run into are assuming the height and width of the viewport can be a problem. Its different dimensions on the iPad. Also, there is much more real estate for the cocoa touch interface that presents the game. Lots of space to use. Icon sizes can be a problem too -- too big or small.
Ready for ES 2? Looks like I am now. :)
Took long enough. Well, looks like my toolkit is now basically OpenGL ES 2 compatible. Same program but will auto detect ES 1/2 and draw appropriately. That is, I can draw 3D stuff with shaders now. Yippie! This will be a help in future games.
Shaders are loading in and drawing. Lots of uniforms being set, if they are present in the programs. One difference with glsl in OpengL 2.x versus OpenGL ES 2 essl is that many of the built in variables are not present. You find yourself loading in the model view matrix, projection matrix, materials information and lighting information into uniforms -- loading in all the things you take for granted. Though, you could hardcode some of these to speed things up. One difference on loading a 4x4 matrix into a uniform is that ES 2 will not let you transpose via the api. But I do only load it in at the beginning of the level. In some ways, ES 2 and OpenGL 3.x and shaders in general are very little guy unfriendly because you happen to have to code this stuff yourself now! eg. doing the hardcore math in the shader etc. That is going to weed people out for sure. I'd expect main changes after this point to just be new shaders and maybe tweaks to add in new uniforms as needed. Might want to fiddle with bump mapping since I'm already passing in tangent and normal information with attributes -- from that I can get the binormal value and a tbn matix. A first small step in this was to make sure I get the tangent data into the mix with regard to loading models.
At some point in the future, I'll do projective shadow mapping. I had implemented it on the mac in the past but not on the iPhone. But I'll have to add in a render to depth from camera view point which is a little more involved.
Still, I had to clean up some loose ends like integrating the new transform stack with unprojection code for tapping.
Huff, still wish iPhone/iPod had multisample. I wonder if, iPad will have multisample?
Definitely coming to a close to the in between making games R&D retrofit phase.
Progress ... huff
Been busy enabling my toolkit to work with OpenGL ES 2. The goal is, if the program detects OpenGL ES 2, then viola you have shaders. I figure many a developer are going down this path. Its a good bridge to iPad and back to the Mac -- especially iPad because the hardware from the get go is going to be ES 2 enabled.
I've been down this road with OpenGL 2.x but going from ES 1 to ES 2 is a much more rocky proposition. Yet, its more rewarding, if you can pull it off. It feels like going from OpenGL 1.x to OpenGL 3.x.
The two difficult parts seem to be replacing the matrix stack operations ( glPushMatrix etc. ) and then integrating vbo with the shaders. uniforms are pretty obvious. Though, attributes need to be set before the program link.
The matrix stuff is straight forward unless you run into a math issue. Math is unforgiving. But its a good review. In the long run, it would appear spinning your own matrix stack operations might lead to some nice optimizations. One thing to look out for is all the man pages are column major when they show matricies. So, you have to do a transpose, if you pass your 4x4 matrix to OpenGL. eg. glLoadMatrixf ( matrix[0] ) ...
The curve with the vbo stuff is glNormalPointer, glVertexPointer and glTexCoordPointer go away and are replaced with glVertexAttribPointer. That is different from OpenGL 2.x. Also, I was not packing my structure right under gcc which created all sorts of fun with attribute buffer offsets. gcc does not recognize pragma pack apparently.
I like to standardize on uniform names. In the long run, I'll build up a library of shaders. So, picking consistent names is an action item early on. Another interesting thing is that shaders can be made binary. A rule of thumb on shaders is to limit setting uniforms as much as possible. So, I plan not to generalize my shaders. That is hardcode the colors and as much stuff into shaders as possible -- or just set the uniform once right after the compile. This can be a big issue on the Mac because you want to avoid the cpu talking to card as much as possible.
Not sure OpenGL Shader Builder in the development tools works consistently with essl ( the OpenGL ES equivalent to OpenGL glsl ). Though, I hear Apple is doing a major upgrade to OpenGL 3.x. I bet this will make things work better with OpenGL ES 2 -- Mac desktop simulator and tools. Maybe the next OpenGL Shader Builder will work. Shader tools on the Mac have always been lacking. No Render Monkey etc. Maybe with iPhone so prominent its time for people to get serious about shader related tools on the Mac.
Looks like you cannot have floating point fbos according to books I've been reading on ES 2. But you can have render to depth which is going to be important for shadowmaps. Since there is no floating point fbo, then ping pongs are going to be limited and you'll get aliasing.
Another difference appears that in ES 2 you have to use shaders. Where as, in Opengl 2.x you could switch between the old fixed pipeline stuff and the shader stuff. So, fixed pipeline really is gone in ES 2.
Much more to do .... all disclaimers apply. Fortunately, there are many similarities between OpenGL ES 2 and plain old OpenGL 2.x.
Not quite enough for any screenshots yet. But good progress so far. Think the most difficult goals in this process have been achieved.
New Project
Today, I decided to start my next project. I'm going to work on my engine ( synonymous with toolkit ) . I'm planning on making my source code compatible with OpenGL ES 2.
Anyhow, the first step is to get a capable piece of hardware. I went out and purchased the 3rd generation iPod touch with 32GB of ram. Now, you have to be careful because the 3rd gen iPod with 8GB of ram still has the old graphics gpu. The project needs the Power VR SGX gpu and not the MBX gpu on the older iPods. The iPhone 3GS has the SGX gpu but I don't want to pay a phone bill. Too bad the 8GB iPod version did not have the SGX gpu.
I had previously tested my games on my brother's iPhone 3GS. The main difference to my surprise, is that moving lights when using OpenGL ES 1 on the SGX gpu caused a stall in the frame rate. After research, I found that changing the lights direction might be causing some recompilation -- there is no fixed pipeline on new hardware ... its all programable. This is one gotcha. Though, I should test this on the latest version of the iPhone OS and see if its changed.
Figure the main things that are going to have to be done is:
1. Determine if its OpenGL ES 2 capable hardware and make the correct context. Examples of this in the default OpenGL ES project template with XCode.
2. Do not use the old lighting and fog models with OpenGL ES 2. Might be other obsolete commands that need to be executed only in OpenGL ES 1. This stuff gets moved into the glsl programs.
3. I'll need to add compilation of glsl programs, setting texture units and passing uniforms to bound glsl programs. This is in the material system -- nix all the old material calls in ES 2. Uniform passing should be minimized as much as possible -- put colors and lighting values in the glsl program. Done this before in OpenGL 2.x programs on the Mac. Should be a similar affair. Though, I would not be surprised, if there is as much of a penalty for uniform passing as there might be on a video card because ( I figure ) the iPod is going to share main memory. I'm assuming, if I don't bind a glsl program, then I get the emulated 'fixed' pipeline behavior.
4. All of the matrix stuff ( push, pop, identity, etc. ) is going to have to be implemented with code I supply. Then supply the matrix to the shader programs.
I'm sure this is just the tip of the iceberg but should be fun. Ordered the OpenGL ES 2 book just in case. Just have to tip toe through the minefield and see which assumptions are correct.
Submitted
Today, I submitted the next Sea Assault update. Its rather close to the last update but I want to make sure the version tested with iPad simulator is released.
I spruced up explosions more and added more sparks to the game. When the helicopter and turrets fire they emit some smoke too. Fixed some other depth kinks with particles that were present in the last version.
To help with ground targets, I added a small red targeting line. This makes it easier to hit ground targets or at least to know where the shots are going to hit when you fire at the ground.
There is a transition animated effect going into and out of game view which is a nice use of Cocoa Touch -- similar to the recent Ant Planet change.
I notice that clicking on links to the iTunes store will also bring up a web page. This is nice because now everyone on the web can see what is available on the store. It use to work only with the iTunes program.
More on updates
The Sea Assault update with the point sprite changes has been released. It fixes other minor things too. The notes are in the support section.
Now, I'm already ready for the next Sea Assault update! ( Gasp ) I had updated before the iPad announcement. But I don't want to update spam users. According to the store documentation, new features need to wait one month and bug fixes need to wait at least two weeks. Only critical updates ( eg program crashing ) warrant an immediate update. The next Sea Assault update is going to put in some changes that got the program working on the iPad simulator -- as a consequence improve the odds on the actual device. I'll probably wait a couple of weeks. Perhaps, I'll wait until the next iPad beta software is released. But Apple said in public they'll start to sell iPads in 60 days. As I said before, the update jam is going to get more pronounced. This update is going to have view switching like Astroidica ... a cool animated effect.
I submitted the next Ant Planet update to the store with the iPad sim changes. This update will have point sprites for particles and some minor improvements. It will also have view switching to game mode like Astroidica has.
Astroidica just worked in the iPad simulator. There were no changes that needed to happen. No need to update Astroidica for now.
After these updates, things should settle down.
Preparing for iPad
I've been working this weekend on getting all three games working on the iPad simulator. I can't give much detail about the specifics because there is beta software developer restrictions. But I will say that the games will work on the iPad. Sea Assault and Ant Planet will have one update to correct some technical issues -- I've already done the fixes. These updates will ensure the iphone/ipod games work on the iPad. They will not add any specific iPad functionality. As Apple demonstrated in public, you will be able to launch the iPhone/iPod based game and there will be a 2x button to enlarge the game's view.
Before the previously described iPad oriented updates, there is a Sea Assault update that fixes some minor issues with the last release and uses point sprites rather than quads for particles.
So, there are three updates in the next 60 days coming down the pipe. I recall from when iPone OS 3.0 came out, there was quite a jam to get updates out. I want to get ahead of the curve this time. I also remember from the 3.0 release, that the store put a check box up to verify that you have tested it on 3.0 -- I wonder if that will happen with iPad too.
Fortunately, I have another disk partition to install the beta software on. I see people getting tripped up like last time when they overwrite their tools with beta software and find out they cannot publish to the store!
Ant Planet Update
I've been working this week on Ant Planet. Since the game is relatively new, the main goal is to iron out any rough edges in the basic game functionality before I add anything new.
I cut the vertices down with Modo on the truck model by roughly half. I reduced some of the other background models too. This gives the game a performance boost and looks 99% the same. If the model is drawn small your not going to see much improvement with a high vert count. Should run better on the 3G phone. I also brightened up some of the colors.
The other main issue was aligning the turret better when the player shoots ... a complicated math problem because the truck might be on a slope while it aiming. But the math issue is resolved.
For kicks, when the truck drives slower the trucking driving sound's gain will lower -- cool if you slow down going up the ant hill. Seemed odd before going slow and having that sound going.
Otherwise, minor fixes.
Think Apple has changed the updating policy. Looks like it takes roughly 2-3 days now where before it was two weeks. Testing and being careful before submission is really important. You will not have a week to realize there is an issue. Gave it a whirl on my devices and things appear much better. Pretty focused update on the current games rough edges.

View Comments