Blog

 Comments from the 'Dev'                                                    

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.

Player Missiles and Jets

I've been a busy bee this weekend.

It makes no sense for a helicopter to shoot a jet with a cannon. First, jets are faster than helicopters. Lining up the cannon was near impossible. You can still try with the cannon but there is another way now.

Enter a new feature. I'll call it a laser tracker. If you have missiles on, then the laser tracker will target the closest jet for a guided missile. The jet has to be visible and close to track. If there is no laser tracker then the missile has the default unguided behavior. So, the player has to stay up with the jet target which is the challenge.  It also makes jets interfere, if you are targeting ground objects -- jets have a reason to be in the game besides flying in circles.

laser

And this jet gets hit by a missile. Nice.

explode

I added orange dots to the radar to show jet positions. Also, a purple square will show up in radar for enemy missiles too. Jets really fill out the space between the islands.

The jets now fire a cannon directly forward sometimes when they show up in the visible view. So, don't get directly in front of a jet. The jet might shoot you first before it runs into you!

The trade off with the jets is chasing them can waste gas and each missile costs 5 points. But its generally a profitable operation.

I resubmitted with these changes too. That should be it for this update! On a roll. Btw, all updates are free to current customers.


Jet Model

Here is a quick render of the jet model that I put into Sea Assault. I've gotten better at using Cheetah3D over the years. In this case, I had to turn the subdivision down and set the smooth angle high. Often, the biggest performance boosts have nothing to do with programming but are simply trying to reduce the vert count on models as much as possible.

jet

Newer versions of my game engine ( toolbox ) use vbos. But since the iPhone/IPod use main memory, it does not make as much of a performance boost as it would with a video card running on a desktop. Though, since new hardware might come along and give benefit to vbos its wiser to make use of it anyways.

If a model is really a unique recognizable item, sometimes I'll buy it on Turbosquid. But its difficult to find low poly models sometimes. The jet is really generic and I could get away creating it myself. For Sea Assault, I did all the model work and art myself.

Sea Assault Update

I added improvements and bug fixes to Sea Assault.

First, there is a new dialog view for when the player lands on the base. Now the player can choose more specifically fuel and missile amounts. It does not auto-calculate the amount anymore. I think that might have confused people and I want to make it more clear. 

note: updated text format for supply store. 1/9/10

supply

I added recon jets to the game. The jets fly in circles around the world and can get in the way. They are difficult to shoot. This adds some activity when flying between the islands. You can bump into them too and it could be a problem, if your dodging stuff around the islands.

jets

There are some other minor improvements. But the supply dialog, vertical movement and the jets are the big items  for this update.


More Screenshots

I uploaded more Ant Planet  screenshots to the website.

Ant Planet Update Submitted

Minor update to Ant Planet today. The update tweaks game controls, improves background obstacle placements and fixes some other minor issues. Typically, updates take roughly two weeks for the store to process.

Update: it looks like it took 4 days for the update to process this time! Now that Apple does not show updates on the phone's new release lists there is less congestion in the store to update apps.

List sites / Reviews

I added the apps to some listing sites. Here are some links at FreshApps ( looks great ) :

http://www.freshapps.com/astroidica

http://www.freshapps.com/ant-planet

http://www.freshapps.com/sea-assault

We have had some interest in reviews. But most of these contacts have had gmail or aol email accounts. Since we cannot verify who you are, we probably did not respond -- we are not going to just hand out promo codes anymore. Also, Reliabit has never paid a 'reviewer' and never will. We feel reviewers need to be as unbiased as possible and give an accurate review to their sites viewers.

©2009-2010 Reliabit,LLC. All rights reserved.