You help a happy-go-lucky square dude escape death by turning his world (the iPhone) left, right, up and down all while he continually skips to his right.

I made the game with my dad . It uses our engine built off of c++, objective c, OpenGLES, XML and OpenAL.
There are 30+ levels each involving different timing puzzles. Take your time progressing levels or go for a highscore by collecting stars along the way as fast as possible. OpenFient’s online gaming community is used to keep track of leaderboards and achievements.

We expect a July 2010 release.

… more on that soon …

Extra Features in Demo:
Beside self-shadowing parallax, I was able to get global shadow maps to work with the parallax occlusion. Because parallax mapping actually takes place on flat geometry, depth comparisons with the light buffer will conclude that something parallaxed is in shadow when it really isn’t; this causes “floating” shadows where no matter how steep the parallax-occlusion becomes, the shadow test still determines shade with the flat piece of geometry. I modified the G-Buffer such that when an object is using parallax-mapping, I alter it’s world-space position in the G-Buffer. This is easy to do via shaders by simply moving the world-space position along the object’s normal*parallax_value.

Deferred Lighting
Steep Parallax Mapping with Soft Shadows
Variance Shadow Maps
Screen Space Motion Blur

Quaternion Slerp( const Quaternion& lhs, const Quaternion& rhs, float t )
{
   float cosAlpha = lhs.Dot( rhs );
   Quaternion r = rhs;

   if( cosAlpha < 0.0f )
   { // if cos(alpha) is positive, then the path from q1 to q2 is shorter.
       r = -1.0f*r;
   }
   cosAlpha = lhs.Dot( r );

   float alpha = acos( cosAlpha );
   if( fabs( alpha ) < epsilon )
   { //< these quaternions are too close to slerp between.
       return lhs;
   }
   float a = sin( ( 1.0f - t ) * alpha ) / sin( alpha );
   float b = sin( t*alpha ) / sin( alpha );
   Quaternion q = a*lhs + b*r;

   q.Normalize(); //< we want a unit quaternion
   return q;
}

Lots of slow trig functions for hundreds of slerps can really bog you down.
Well, this article by Jonathan Blow has a nice hack that approximates slerp. It uses generic lerp between two quaternions and then normalizes the quaternion to project it back onto the unit sphere.
Our new code looks something like…

Quaternion Slerp( const Quaternion& lhs, const Quaternion& rhs, float t )
{
   Quaternion hackQuat;
   hackQuat.x = lhs.x + t*(rhs.x – lhs.x);
   hackQuat.y = lhs.y + t*(rhs.y – lhs.y);
   hackQuat.z = lhs.z + t*(rhs.z – lhs.z);
   hackQuat.w = lhs.w + t*(rhs.w – lhs.w);

   hackQuat.Normalize();
   return hackQuat;
}

Of course, a better method would be to just implement incremental slerp which is both computationally fast and takes care of any speed issues.

Implementing soft particles is a way to alleviate the harsh collision that occurs between particle sprites and existing geometry. If you are doing deferred rendering you probably already have some way of retrieving your scene’s depth buffer. While rendering the particles into your scene, alpha blend out fragments who’s depth is close the the existing scene’s depth. You can make a simple fade out function such as:
D = clamp( ( Zscene – Zparticle ) * scale, 0.0, 1.0 ).

Nvidia’s article on soft particles, however, recommends using a piecewise function or a smoother function to create a nicer fadeout. Here is my soft particle using a smoothing curve.

Deferred shading is a shading algorithm where information is stored to several intermediate buffers instead of straight to the color buffer. Many times, in forward rendering, lighting calculations will be spent on fragments that end up being overwritten by occluding objects in the scene. The idea behind deferred shading is that we hold off on lighting calculations until needed.

1) Render all the geometry of your scene to a G-Buffer. The G-Buffer will hold fragment normals, positions and any other information you’d need to have later on for your lighting calculation. Usually the following step-up will get you far enough along to see some results…
Render Target1: gl_FragData[0] = 3DPosition.x, 3DPosition.y, 3DPosition.z, Free
Render Target2: gl_FragData[1] = Diffuse.r, Diffuse.g, Diffuse.b, Specular
Render Target3: gl_FragData[2] = Normal.x, Normal.y, Normal.z, Free
However, you’ll want to optimize this setup based on your hardware caps.
Tip: Storing only Normal.x and Normal.y you can re-derive Normal.z later knowing that it has unit length.
Tip: You derive Position.xyz for each pixel by using 2D screen coordinates and a reconstructed linear depth.
2) Now that you have the G-Buffer you can run your global lighting shader by passing in the G-Buffer and exciting each pixel on the screen with a full-screen quad. The global lighting shader will use the information from the g-buffer to light everything on screen.
3) Local lighting works the same way. “Excite” only the pixels you want to light by rending small spheres or cones or whatever. This will, in-turn, ignite the fragment shader to work on only parts of the scene that are effected by each local light.
4) Sky’s the limit… do what ever post-processing effect you want. Just know that the idea here is run calculation on as few pixels as possible. If you have 100 HUGE local lights that fill the entire screen 100xtimes over, you’re missing the point.
There are many optimizations to be have, I’ll touch on these later.

PS: I created the cloth using springs and Verlet integration.