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.