Using PID Controller

Introduction
Several weeks ago, I need to implement a game screen for user to choose a level. At that time, I read some post and article about using PID controller for controlling the behavior of a system, so I decided to try it on the UI. PID controller is a control loop feedback mechanism which generate an output to a system based on the difference between a measured value and a desired value:

where f(t) is the output apply back to the system, e(t) is the difference between a measured value and a desired value and P, I, D are tuning variable for controlling the behavior. More information can be found on this post.

Using PID Controller
In the UI, the user can drag on the view to choose the level, when the user swipe on the icons, they will scroll according to velocity and acceleration. The output of PID Controller is used to control the acceleration so that there will always be an icon staying in the middle of the screen when the system becomes stable. The code is ported to WebGL as below(need a WebGL enabled browser to view):

Your browser does not support the canvas tag/WebGL. This is a static example of what would be seen.
P: I: D:

 
 

Tuning the PID variables

The behavior of the scrolling can be controlled by tuning the constants: P, I, D. The effects of changing the 3 constants can be summarized as below:
Summary of the effects of PID constant from Wikipedia
You can play around with the 3 Constants with the input text field above if you have a WebGL enabled browser.

Conclusion
Using PID Controller to manage the system is convenient but it is a bit tricky to tune the PID constants. It is easier to tune the constant one by one and referring to the above table. The source code of my implementation can be downloaded here.

Reference:
[1]: http://en.wikipedia.org/wiki/PID_controller
[2]: http://altdevblogaday.com/2011/08/07/animation-using-closed-loop-control/
[3]: http://altdevblogaday.com/2011/02/27/webgl-part-2-in-the-beginning-there-was/
[4]: http://www.learnopengles.com/how-to-embed-webgl-into-a-wordpress-post/

Writing an iPhone Game Engine (Part 6- Performance)

Introduction
Performance of a game is very important, it is important to maintain a constant frame rate of a game. So I will talk about how I keep track of the performance of the game. However, the game is not finished, I can only profile the engine with sample placeholder assets, the profiled data might not be match with the final data after the game is finished. Anyway, I will try to talk about my first attempt to profile my engine. (All the data are measured with iPhone 3G).

XCode OpenGL ES Analysis
For profiling the graphics performance on iPhone, there is an OpenGL ES analyzer that comes with Xcode 4. It can detect redundant state changes and give some advice to improve rendering performance. It also help me to spot some bugs such as forgetting to set the texture states to use mip-map.
After using the analyzer, I discover that 2 recommendations that improve my engine rendering performance significantly. The first suggestion is to use the EXT_discard_framebuffer extension after rendering each frame.
Before using the analyzer, I did not notice iPhone have this OpenGL extension. This helps the frame rate from 20.8ms per frame to 19.2ms per frame. The second suggestion is to use a more compact back-buffer format to reduce the fill rate.
After setting the back-buffer format from RGBA8888 to RGB565, the time taken for each frame reduced from 19.2ms per frame to 18.52ms per frame.

Performance Graph
I also generate a  performance graph to display how much time each subsystem is used in the engine. It is easier to have a graph to spot spikes of the game so that I can investigate which subsystem cast the spikes.

Conclusion
The above 2 techniques are used to track down the performance issues and increase the frame rate. However, as the game is still under development, there are still some area, such as physics and script, which can be optimized. Those optimization will be done when most of the game is completed. I am going to stop writing this series as most of the problems I have encountered during development are mentioned. May be I will write a postmortem after the game is finished, but this will not in the near future as there are still tons of art-work have not been done yet. Hope you all enjoyed the series.