Thursday, October 21, 2010

OpenGL Rendering Pipeline

OpenGL Pipeline has a series of processing stages in order. Two graphical information, vertex-based data and pixel-based data, are processed through the pipeline, combined together then written into the frame buffer. Notice that OpenGL can send the processed data back to your application. (See the grey colour lines)

 
OpenGL Pipeline

Display List

Display list is a group of OpenGL commands that have been stored (compiled) for later execution. All data, geometry (vertex) and pixel data, can be stored in a display list. It may improve performance since commands and data are cached in a display list. When OpenGL program runs on the network, you can reduce data transmission over the network by using display list. Since display lists are part of server state and reside on the server machine, the client machine needs to send commands and data only once to server's display list. (See more details in Display List.)  

Vertex Operation

Each vertex and normal coordinates are transformed by GL_MODELVIEW matrix (from object coordinates to eye coordinates). Also, if lighting is enabled, the lighting calculation per vertex is performed using the transformed vertex and normal data. This lighting calculation updates new color of the vertex. (See more details in Transformation)  

Primitive Assembly

After vertex operation, the primitives (point, line, and polygon) are transformed once again by projection matrix then clipped by viewing volume clipping planes; from eye coordinates to clip coordinates. After that, perspective division by w occurs and viewport transform is applied in order to map 3D scene to window space coordinates. Last thing to do in Primitive Assembly is culling test if culling is enabled.
 

Pixel Transfer Operation

After the pixels from client's memory are unpacked(read), the data are performed scaling, bias, mapping and clamping. These operations are called Pixel Transfer Operation. The transferred data are either stored in texture memory or rasterized directly to fragments.  

Texture Memory

Texture images are loaded into texture memory to be applied onto geometric objects.  

Raterization

Rasterization is the conversion of both geometric and pixel data into fragment. Fragments are a rectangular array containing color, depth, line width, point size and antialiasing calculations (GL_POINT_SMOOTH, GL_LINE_SMOOTH, GL_POLYGON_SMOOTH). If shading mode is GL_FILL, then the interior pixels (area) of polygon will be filled at this stage. Each fragment corresponds to a pixel in the frame buffer. 

Fragment Operation
It is the last process to convert fragments to pixels onto frame buffer. The first process in this stage is texel generation; A texture element is generated from texture memory and it is applied to the each fragment. Then fog calculations are applied. After that, there are several fragment tests follow in order; Scissor Test ⇒ Alpha Test ⇒ Stencil Test ⇒ Depth Test.
Finally, blending, dithering, logical operation and masking by bitmask are performed and actual pixel data are stored in frame buffer. 

Feedback

OpenGL can return most of current states and information through glGet*() and glIsEnabled()commands. Further more, you can read a rectangular area of pixel data from frame buffer usingglReadPixels(), and get fully transformed vertex data using glRenderMode(GL_FEEDBACK).glCopyPixels() does not return pixel data to the specified system memory, but copy them back to the another frame buffer, for example, from front buffer to back buffer. 

Apple's External Accessory framework



Apple came up with an fantastic accessory framework for other devices or gadgets to work with Iphone, Ipod and IPad. This particular program is known as MFI (Made For Iphone, Made For Ipad, Made For Ipod). The Made for iPod, Made for iPhone, and Made for iPad logos mean that an electronic accessory has been designed to connect specifically to iPod, iPhone, or iPad and has been certified by the developer to meet Apple performance standards.Developers receive technical specifications describing the iPod Accessory protocol, the communication protocol used to interact with iPod, iPhone, and iPad. Developers also gain access to the hardware connectors and components that are required to manufacture iPod, iPhone, and iPad accessories.

For more info refer link  http://developer.apple.com/programs/mfi/


For Using External Accessory Framework with Bluetooth devices refer the following link
http://developer.apple.com/library/ios/#qa/qa2009/qa1657.html

Monday, October 18, 2010

Framework for building 2d games for Iphone, Ipad and Ipod Touch

cocos2d for iPhone is a framework for building 2D games, demos, and other graphical/interactive applications. It is based on the cocos2d design: it uses the same API, but instead of using python it uses objective-c.







Main features

  • Scene management (workflow)
  • Transitions between scenes
  • Sprites and Sprite Sheets
  • Effects: Lens, Ripple, Waves, Liquid, Twirl, etc.
  • Actions (behaviors):
    • Trasformation Actions: Move, Rotate, Scale, Jump, etc.
    • Composable actions: Sequence, Spawn, Repeat, Reverse
    • Ease Actions: Exp, Sin, Cubic, etc.
    • Misc actions: CallFunc, OrbitCamera
  • Basic menus and buttons
  • Integrated Box2d and Chipmunk physics engine
  • Particle system
  • Text rendering support
  • Texture Atlas support
  • Tile Map support
  • Parallax scrolling support
  • Streak Motion support
  • High Score server (Cocos Live)
  • Touch/Accelerometer support
  • Sound support
  • Portrait and Landscape mode
  • Integrated Pause/Resume
  • Supports PowerVR Texture Compression (PVRTC) format
  • Language: objective-c
  • Open Source: Compatible with open and closed source projects
  • OpenGL ES 1.1 based


For more details refer http://code.google.com/p/cocos2d-iphone/ 

Basic Note on UIImage

UIImage
Its a wrapper to the existing CGImage class. CG refers to core graphics and is basically C API's with whole lot of features.

- In the case of imageNamed: method the image is actually cached by the OS .All the subsequent calls will return the cached image. However with imageWithContentsOfFile: method the image is lazily loaded on demand.Lazy loading is one of the key point to be considered for better performance.

Relevance:
- Avoid loading many images at once, particularly in the applicationDidFinishLaunching: or viewDidLoad: method. This can slow down the application or the view that is to be loaded.
- Iphone OS itself uses the imageNamed: to load the images from the NIB

When to use imageWithContentsOfFile:
- Any image that is not needed immediately
- images used infrequently or rarely. This is to avoid the OS caching images that are not used frequently in turn not pressurizing OS cache.

Memory Mangament in iPhone


Memory management with Iphone becomes mandatory , as the iphone OS donot handle garbage collection. Apple has not included the feature of memory management , with concern that , the burden on the IPhone OS will be more. The disadvatage of this is the application crashes from the user prespective . But the advantage with this is with the programmers to some extent, because the user will have the flexibility of playing around    with memory.

Here are some of the possibilities that would lead to crash if memory is not mangaed properly.

1) First and foremost that an iphone programmer needs to know is how the retain count for the objects work.
Once you allocate an object then the retain count will be 1. If you retain the same for further computation then the retain count increases by 1 again . So totoally the retain count becomes 2.
Therefore before the scope ends , the object should be released twice.Here is the sample code snippet that explains the same.
NSString *string1=[[NSString alloc] init]; // retain count = 1
NSString *string1Copy = [string1 retain] ; // retain count = 2

2) Try using Instruments to check for any memory leaks . Visit the following the following site given by apple.

3) If the code block uses too much memory and if your not sure about the release useNSAutoReleasePool . Make sure u release this pool before the scope ends.

4) Try not using autorelease as much as possible

5) Handling of delegates : This is very important since , in the code if u assign an object to a delegate and u deallocate the object without clearing the reference , error is thrown as deallocated object is referenced , since the delegate references the object that is already released

Shake feature in iphone


IPhone is known for its fascinating features and shake feature is one of the kind.Iphone has 2 event features as touch and motion.
Lot of apps pertaining to the shake feature has successfully made its place in the app store, due to its effective utilisation.Here are the 3 methods that implements the shake feature:

- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionCancelled:(UIEventSubtype)motion withEvent:(UIEvent *)event;
- (void)motionEnded:(UIEventSubtype)motion withEvent:(UIEvent *)event;

As an example consider the following:

- (void)motionBegan:(UIEventSubtype)motion withEvent:(UIEvent *)event
{

UIAlertView *alert=[[UIAlertView alloc] initWithTitle:@"TEST"
 message:@"Shake feature Implelmented" delegate:nil
cancelButtonTitle:@"Cancel "
otherButtonTitles:@" OK ",nil];
[alert show];
[alert release];
}

The above code snippet does nothing great , rather than displaying an alert notifying the use of Shake feature in iphone