Monday, December 21, 2009
MotionInk Free for 24 hours
Wednesday, September 2, 2009
The end of project crunch!! Feverous
Saturday, August 8, 2009
Ramblings about Scene graphs and CocosNode
Every non trivial graphical application houses within it some form of data structure that organizes the placement and grouping of the objects that need to be rendered to the screen. The data structure used is most often represented as a collection of discreet data blocks linked to each other in a parent child relationship. The data blocks can house many different types of information useful to applications rendering passes.
A scene graph is a high level spatial data structure that organizes visual data in a tree made up of a collection of nodes. A node may have many children but will often only have a single parent. The transformation and render state data of the parent node provides context for the child nodes. An operation applied to a parent node automatically propagates its effect to all of its children unless purposely blocked. As a spatial implementation of the Composite design pattern scene graphs allows groups of graphical data or nodes to be treated as a singular node.
The Composite pattern specifies Components, leaves and Composites as it structural components. It describes a means of composing objects into tree structures to represent object hierarchies. The whole of the composite is made up of it's parts and each part can be viewed as identical in the composite. In a scene graph the node class is used for all 3 of the above structures. The base node class implementation has at least member variables referencing it's parent nodes and a collection of children nodes. The references between the nodes are used to form the structure of the scene graph.
In the Cocos2d-IPhone framework's scene graph implementation CocosNode is the basic node class. The CocosNode class houses a single pointer to it's parent node and an NSMutableArray of pointers to any children nodes it may have. CocosNode objects also maintain an NSMutableDictionary of Selectors (callback function pointers kinda, well talk about these in a future post) and data members for size, position and rotation data.
Since the CocosNode class is the base of the node inheritance hierarchy it doesn't do much on its own. It is an object with no size and no sprite or texture information that cannot except touches or accelerometer data. The CocosNode derived classes provide the majority of the special functionality required to create a usable Cocos2d-IPhone based touch application. The majority of these classes add enough functionality that each should really get its own post. I will introduce some of the more necessary CocosNode derived classes here and describe some of the functionality they add to the base node class. Remember, when all else fails and you cannot find a CocosNode derived class that does what you need you can always derive your own and add your special functionality.
On a side note, your general workflow for using Cocos2d in you applications will most likely be to subclass one of the CocosNode derived classes, add custom code in it to manipulate its properties and or its children nodes properties, instance the derived class and push the instance into the scene graph. There are a few exceptions Sprite, the canned particle effects, and Menu for example where you can instance without subclassing, but you should get comfortable with subclassing.
Any node can be the root of a scene graph data structure. Some scene graph implementations provide a base node subclass who's only purpose is to act as the root of a scene. The Cocos2d-IPhone Scene class when instanced creates such a node and it or a derivative of it should act as the root node for all of your in application's scenes. Scene class instances are anchored at there center and are no different than the base CocosNode in any other respect.
If you review my previous post on the Director class you probably recognize that I created a blank generic scene in the example code and ran with it. In a real simple example application it would be useful to create a credits/splash scene, a menu scene, and maybe a gameplay scene. Each a scene represents a logical unit of functionality and can be used to organize interface mode transition and flow. For example the splash scene go be set to display for a short period of time and then the menu scene could run and wait for the user to select a menu item transitioning the application to the gameplay scene. I generally like for my scenes to be instanced in the Director as it is a singleton that can be found easily but there are many ways to skin a cat.
The Layer Class is probably the first do something CocosNode derivative that you will encounter. Before we go into what it does lets discuss what layers represent. (Warning: The aspect of layers I am about to discuss is not represented by any special functions or member variables. This is just an opinion/understanding I came across.)
Layers could be seen as analogous to transparent sheets stacked along an axis exactly on top of each other. In the areas of a layer that don't contain content, you can see through to the layers below. Layers in Cocos2d allow cartoon cell style imagery in a scene. For example you can have one layer as a the background of the scene, One representing the score or some other textual data and another with actions moving visual objects around the scene. Objects in one layer may partially or fully occlude objects in the layer beneath it during the running of the application.
Cocos2d layer class instances are command and control nodes. Instances of the layer class can take in the touch and accelerometer data that represents the users interaction on the IPhone platform. Layer is a canned conduit for you the developer to allow the user to interact with your application in a special way. I will go into the Layer and Touch delegation in more detail in a future post. The Layer class has a couple of derived classes that allow for coloration and multiplexing. Coloration is simply allowing the tinting of a Layer. Multiplexing in this context is about having a set of layers being mutually exclusive and not visible together. Maybe useful for separate selection screens or multiple menu hierarchies.
I am going to finish this post with a small discussion of the TextureNode, Sprite and AtlasSprite CocosNode derivatives. Each of the classes is primarily concerned with the getting image data to the screen. I consider instances of these classes to be primarily leaf nodes in the scene graph.
TextureNode simply allows a specified image to be rendered to the screen. It handles the work involved to import and render an image in OpenGL (you should try to do this using opengl calls so you appreciate the class).
Sprite is concerned with sprite rendering and simple sprite animation (think gif) and allows you to use individual images to do sprite based animation. Using Sprite and its individual image based animation implementation can be memory consumptive and slow. I could see using the Sprite class initially in a project to get things set up and looking good an then moving on to the AtlasSprite Class and a texture atlas once you are actually producing something for App Store consumption.
The AtlasSprite class allows for a collection of visual data to be specified in a single image generally called a texture atlas. The AtlasSprite and its manager class controls the navigation of the texture atlas moving around to the indexed part of the texture and render a set of pixels from the location. Texture atlas-ing is a topic unto itself so i'll stop at that until later.
This concludes this post. Next time I will talk about Actions, Transistions and callback selectors. Thanks for reading!
PS: I am trying to get code printing pretty but its not working out well. Once I figure it out I will be adding code examples to this post.
Tuesday, July 28, 2009
Ramblings about the Cocos2d Director class
Director is the class that acts as a binding agent linking the Cocos2d Scene management system to the UIKit framework. It takes over control of application flow, most commonly, in the UIApplicationDelegate applicationDidFinishLaunching function override. There are 2 different "types" of Director. The normal director and a higher performance fast director. The director maintains the applications main run loop, runs the initial scene and houses the functions that start and stop the main run and animation loops.
Encapsulated in the Director is the one and only EAGLView instance. This our rendering surface and is where all of the drawing for our Cocos2d based application happens. The EAGLView is backed by CAEAGLLayer which is an especially talented core animation layer that has an OpenGL ES rendering context. As I stated in the previous post this is not an OpenGL ES tutorial. Being satisfied in the knowledge that Cocos2d will be handling all of the OpenGL ES kung fu for you will allow you to focus on the specifics of your particular project. After a while using Cocos2d for IPhone go back and optimize the parts that require special attention for usage in your application. The whole point is not to reinvent the wheel.
The simple sample code below sets up a director for an application in landscape mode, that shows the frames per second and runs with a Scene. Also observe the main loop control functions being called in the application delegates applicationWillTerminate, applicationWillResignActive, and applicationDidBecomeActive functions.
Next post I will be focusing on the CocosNode class and Node inheritance hierarchy. I will also discuss scene graphs and how the Cocos2d Nodes realize the composite design pattern.
Sunday, July 26, 2009
Cocos2d for IPhone Ramblings: Pref
BTW: I wont be giving any sort of C, Obj-C or XCode primer so before I start my second post on this thread go out and google up some Obj-C and XCode goodness. I will also not be going into introduction of OpenGL ES because there are volumes written on the subject. I like Jeff Lemarche's OpenGL ES from the ground up series. It is a great introduction to OpenGL ES written specifically for IPhone/IPod Touch by someone who writes books on the subject of IPhone development specifically.
Cocos2d for IPhone is an open source project under the GNU LGPL hosted on google code at cocos2d-iphone. It is a port of the Cocos2d Python framework re-implemented in the Objective-c programming language for use on the IPhone and IPod Touch by Ricardo Quesada and company. Go thank them and contribute, they deserve it.
Cocos2d sits on top of OpenGL ES abstracting away most of the more tedious time consuming aspects of OpenGl based 2d programming. Fact is you can use the framework without writing a lick of OpenGL rendering code. You can also dip down into the lower levels of the framework and change the underlaying OpenGL calls as all of the source code for the framework is at your disposal in the distribution.
My little ramblings about Cocos2d do not live in a vacuum. There are many other blog based Cocos2d programming tutorials covering basic usage, project creation and XCode integration, and even some fully implemented game source code to learn from. They are written by much more notable IPhone dev community members than I (The list of links above is not exhaustive). I will cover some of the same material but will be more concerned with looking at the architecture, object model and implementation details of the framework than creating an operational game. I will try to post at least once a week day job, side job and family permitting.
As you can probably see by this initial post I am a little hyperlink happy. I have a preference to linking directly to content specific to subject matter rather than paraphrase some other persons more thorough explanation. Please forgive this habit in advance.
Kenneth A. Barber
