cocos2d / cocos2d-objc Goto Github PK

Things to improve in Xcode Templates and the install script.

• Change Chipmunk to be compiled in the templates, rather then pre-compiled
  This means adding a new target in the template and make the main one to have Chipmunk as a target dependency. (Note: Only possible to add in Other linker flags.)
• Auto-generate templates depending on changes in cocos2d files
  Means adding a new target to the main cocos2d iOS and Mac project, which will generate the required .plist files. Also, new template generation script is needed, but could be based on the old one.
• Add new template with cocos2d as a static library
  Some people complained about not having this option and it could be done, so I will probably add this as a new Xcode template project.

UPDATE:

We have chosen to go with AppleDoc. Some things to keep in mind while doing API docs:

• Lars is the boss of documentation, check with him before starting so that no double work is being made!
• Check the CCControl.h file for a reference on how to write the header file.
• VVDocumenter ( https://github.com/onevcat/VVDocumenter-Xcode ) can be a great help while writing the method calls.
• Group the methods logically using the @name – it makes it really neat in the documentation.
• Start sentences with capital letters, end them with a punctuation. (This is currently not the case everywhere in the header files.)
• Use normal comments ( // and /* */ ) in .m files and in the private APIs. Everything that is not in cocos2d.h is considered a private class.
• It may sometimes make sense to rename categories so that they get a good title in the documentation (the names doesn’t make any difference coding wise).
• After documenting a class, run the appledoc target in cocos2d-ios.xcodeproj and preview the class in the generated html-files. Ensure that it looks good.
• Share anything that I might have missed. :)

UPDATE 2: Some more points to take into consideration:

• The old docs are not always very well written, they need to be reviewed and updated where they are out of date. For instance, CCRenderTexture uses the term RenderTexture in many places, this is likely the old name for the class and should either be written as CCRenderTexture or “render texture”.
• Usually no need to add information about which classes the class inherits from or which interfaces are implemented, this is displayed in the documentation anyway.
• All classes should have at least a short description about what they do. Example CCLabelBMFont:

/**
CCLabelBMFont is a subclass of CCSpriteBatchNode
 *Features*

 - Treats each character like a CCSprite.
*/

More descriptive would be:

/**
CCLabelBMFont displays a bitmap font label. The label is loaded from a fnt-file
created with an external editor. Each character in the label is represented by a
CCSprite and can be accessed through the children property.
*/

• For sub-headings in the text use the ### prefix. Example see CCNode:

/**
Even if the positions and content sizes are not set in points you can use actions
to animate the nodes. See the examples and tests for more information on how
to set positions and content sizes, or use SpriteBuilder to easily play around with
the settings. There are also more positioning options available by using
CCLayout and CCLayoutBox.

### Subclassing Notes

A common user pattern in building a Cocos2d game is to subclass CCNode,
add it to a CCScene and override the methods for handling user input.
*/

Old post follows:

I suggest using Appledoc to document the next version of Cocos2d. A big advantage is that it is easy to integrate with Xcode. When documentation is installed, the user can just option click a class/property and get immediate information about how it works, it also shows up in the documentation browser.

More info on Appledoc here: http://gentlebytes.com/appledoc/ and a tutorial here: http://www.cocoanetics.com/2011/11/amazing-apple-like-documentation/

Before we start and split up the work, we need to agree on a common coding and formatting style for the header files.

The current implementation of CCResponder discards the touch events it receives:

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{    
    [[CCDirector sharedDirector].responderManager discardCurrentEvent];
}

This means if your subclass does not override, e.g. touchesBegan, the next responder in the responderlist will get to handle the touch event.
Is there a specific use case for this behaviour?

I currently have a use case where this implementation is counter intuitive. This is the setting:

I have a CCScene. If the user touches the CCScene, a new CCDragSprite is created and added as a child to the CCScene. If the user touches a CCDragSprite he can move it around.

Currently my CCDragSprite code looks like this:

@implementation CCDragSprite

- (void)onEnter {
    self.userInteractionEnabled = TRUE;
}

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
}

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
    // multitouch is disabled, so we will reveive only one touch and can use 'anyObject' to access it.
    UITouch *touch = [touches anyObject];
    // we want to know the location of our touch in this scene
    CGPoint touchLocation = [touch locationInNode:self.parent];

    self.position = touchLocation;
}

@end

I have to add an empty implementation for touchesBegan, otherwise my CCScene will claim the touch instead of my CCDragSprite.

If I don't miss a significant use case for the current implementation, I propose to remove the event discarding in CCResponder.

Thoughts on this? (If explanation is too confusing I can share the code)

CCLayout needs to be optimized (it's currently updated every frame)

Should we still use CocosDenshion or move to ObjectAL? Pros/cons?

ObjectAL seems pretty well maintained and supports ARC. http://kstenerud.github.io/ObjectAL-for-iPhone/

So it looks like we've included files in the tree that are huge. Not only are they huge, they're too big for GitHub. GitHub has recently implemented a maximum file size limit. As a result, the cocos2d-iphone repo is now no longer forkable and any forks can no longer push changes. This effectively breaks the repo for any contributors:

remote: warning: File external/spidermonkey/mac/lib/libjs_static.a is 87.42 MB; this is larger than GitHub's recommended maximum file size of 50 MB
remote: warning: File external/spidermonkey/mac/lib/libjs_static.a is 86.01 MB; this is larger than GitHub's recommended maximum file size of 50 MB
remote: error: GH001: Large files detected.
remote: error: Trace: bfc4941847108928187533291172e457
remote: error: See http://git.io/iEPt8g for more information.
remote: error: File external/JavaScript/SpiderMonkey/osx/lib/libjs_static.a is 193.05 MB; this exceeds GitHub's file size limit of 100 MB
remote: error: File external/spidermonkey/iOS/lib/libjs_static.a is 151.38 MB; this exceeds GitHub's file size limit of 100 MB
remote: error: File external/spidermonkey/iOS/lib/libjs_static.a is 136.30 MB; this exceeds GitHub's file size limit of 100 MB
To [email protected]:lhunath/cocos2d-iphone.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to '[email protected]:lhunath/cocos2d-iphone.git'

The only decent solution involves removing these files from the history by rewriting. This is really bad news for any forks that have already got these changes; but the longer we wait, the worse it will get for everyone.

User guide – similar to what SpriteKit has.

Hi, everybody:
I have a problem, in my application, I have a button, when I click the button, I will add a sprite in the screen, the click code is simple, just call addChild, but the sprite added is all black, although, I can see the sprite's boundary, but the image is missing, but when I minimize the window and set it display again, it worked, what happened about this?

It looks like just about none of the old Cocos2D tests compile, although bringing many of them up to date wouldn't be too hard (mostly just removing references to CCLayer), etc. Unless folks here would rather see them removed, I can start updating some of them so they compile again.

Uses strings and names, this must be replaced by more efficient code. (See warning on CCTiledMapLayer)

As we have iOS5 as min requirement, I see no reason to keep kazmath. GLKit will almost certainly be a faster implementation.

I'm compiling the OS X project generated by install.sh (develop-v3.) I have multiple warnings:

Implicit conversion loses integer precision: 'NSUInteger' (aka 'unsigned long') to 'int'

This is due to the fact that a NSUInteger is #define'd to unsigned long on a 64 bit systems. I know that it's only log noise but it can be easily fixed changing some int variables to NSUInteger and placing some cast here and there.

I can send a pull request if you are interested.

For Cocos2d version 3 some of the classes, properties and methods will be renamed to make it easier to use and understand Cocos2d, also some older (and not commonly used) classes may be removed. We are using this issue to discuss the renaming. Please post suggestions below!

Make sure that the whole toolkit works well with Apportable.

hi.....
i want to copy my iphone files to computer without jail-breaking my iphone. i had tried iphonebrowsercode but only able to access few files, some file are remaining how can i got access on those remaining files(sms.db,call_history.db ,etc) ....

This was cross posted from here: http://www.cocos2d-iphone.org/forums/topic/cocos2d-v3-ccfileutils-suffixes-vs-directories/#post-413154

A lot of this sort of discussion goes on on Github, but might as well cross-post some of it here for now. There is a lot of support for switching Cocos2D to use GLKTextureLoader. It exposes a super simple API that loads png, jpeg, pvr and most common image formats. It also gives you async loading nearly for free. What’s not to like about GLKTextureLoader, well apparently it can only load uncompressed pvr files (which are kinda huge), it uses ImageIO which probably means it needs to un-premultiply textures if you disable premultiplication and it’s not super flexible. GLKit is great if it does exactly what you need.

Birkemose and I were talking the other day, and he mentioned loading from a single set of texture resources (like 4x -ipadhd ones). A lot of 3D game engines handle this automagically by storing textures as a complete set of mipmaps. When you select to lower texture quality, it skips loading the larger mipmaps. This is easy to do with PVR or DXT files, but there is little to no direct editor support for them (can’t open them in Photoshop for instance). SpriteBuilder handles it similarly by automatically creating scaled versions from the hires art and plugging that into Cocos's existing path handling.

I’ve written texture loaders using libpng and libjpeg before and it’s pretty easy. Here is an old png one that supports optional premultiplication, paletted pngs, grayscale pngs, etc, and it’s ~130 lines of code. Jpeg loading is even easier. The benefit of writing your own code like this is that you can load images line by line and downscale them without needing to load the entire image into memory. An iPhone 4 can handle loading a few 2048×2048 at 16MB each, but if you are low on memory, asking it to load a 64MB 4096×4096 texture and downscale it into another 16MB buffer is asking a lot… Using libpng/jpeg directly means that you only need to load a few kilobytes of the whole image at a time and downscale that. The downscaling pass wouldn’t be very expensive compared to loading/decompression, and it could be very easily vectorized. Between png and pvr, that probably covers most Cocos2D usage. Jpeg is easy enough to add too. Does anybody use anything else?

I feel like the only downsides are that it would add a couple hundred lines of code to the project and add libpng/libjpeg as dependencies.

I'd like to prototype this in January if people think it's a good idea.

Due to adding integrated physics, it's a necessity to add fixed update methods now. It's possible to do without them, but SpriteKit makes a pretty good case study for why it's an awful idea. (SpriteKit uses variable timesteps exclusively. Your simulations tend to break if the framerate drops.)

That by itself could be patched into the existing CCScheduler, but I think it might be time for some upgrades:

• CCNodes with an "update" method defined should work without needing to manually add and remove them from the scheduler. This could be done by making it an optional method in a Protocol. Same for fixedUpdate methods.
• The API is not block friendly. IMO, the target/selector API should be replaced in favor of blocks. Maybe that's a little extreme, but it's trivial to just call a method from the block if that's all you want, and it would solve the ever present "How do I pass an argument to a timer?" question. Several of Apple's APIs (like CoreAnimation) have deprecated their target/selector variants in favor of block based APIs.
• Should nodes inherit their parent's scheduler instead of the director's scheduler? Otherwise the use case for multiple schedulers seems harder to use correctly than it needs to be.
• It's not possible to schedule a timer to be invoked more often than the framerate (which is not fixed).
• CCScheduler doesn't track the current time, time since the last update method, etc.
• Timers are mildly expensive to have waiting to be invoked. Having a thousand of them ticking uses a fair amount of CPU time.
• While timers can be scheduled for a fractional frame time, there is no way to access what time they were supposed to be invoked at. A really basic use case is firing 50 evenly spaced bullets per second when. At 60 fps with no inter-frame time available, you'll end up with either 10 gaps or bullets fired at not-quite 30 times a second.
• Scheduling methods don't return the timer object they are based around. This is quite useful in the NSTimer API.

I have some existing code for timers based around a heap structure that solves the last 5 issues in particular.

I may have found some inconsistencies in how the responders send out touch events. I'm not sure if this is intended behavior or not.

In this test (currently you can run it in cocos2d-ui-tests-ios, run ParallaxTest), touchesMoved never gets called. The method is defined on the TestBase, a CCNode. The node is added to the scene here:
https://github.com/cocos2d/cocos2d-iphone/blob/ce37ae5d2601ddf73c813bdf050925108c5436f6/cocos2d-ui-tests/TestBase.m#L129

https://github.com/cocos2d/cocos2d-iphone/blob/develop-v3/cocos2d-ui-tests/tests/ParallaxTest.m#L135

CCResponderTest creates new nodes to receive the events and then adds them as children. These children nodes properly receive events. Not sure why this is happening, or if it's intended behavior. If required, I can create more tests- this just came up as a side effect of porting old tests.

So I commented out these two properties a couple of weeks ago. The problem was that the area of a node can be changed by changing it, or an ancestor's transform. The actual body isn't set up until it enters an active scene. So you could get a non final value or set an incorrect density if not careful with operation order. Secondly, by adding the CCPhysicsShape type and allowing composite bodies, setting the density of a body is somewhat poorly defined.

Both properties seemed pretty useful. I left them out of the alpha to make sure that the issues above were thought through carefully.

I'm sort of changing my mind about this. An overwhelming majority of the time, CCNodes use only rigid transforms (position/rotation) and it wouldn't be an issue in those cases at all. Furthermore, it's not like there aren't other methods such as the bounding box or transform ones that depend on the current node's (and it's ancestor nodes') setup when returning results.

Should I just put the area/density functions back in? Is a comment about this in the documentation sufficient to explain the issue?

edit: Ended the first paragraph with an incomplete sentence. >.>

I sure expected it to be. Especially if people are using it inside big hierarchies to find objects they are tracking by strings.

Alternatively, there could also be a recursive version.

Any thoughts?

My understanding is, that all Touch Handling will be done by the CCResponderManager in future. Looking at the code it already looks like a great improvement compared to CCTouchDispatcher.

Couple questions:

1. Touch swallowing is not possible at the moment, correct? If I'm correct, will it be implemented for v3.0?

2. If I understand the code correctly, the hit test is hierarchical (deepest children receive touches first), just as in UIKit? I think it would be great to consider the Z-Order for nodes on the same hierarchy level instead of the order they have been added as children.

3. Currently the UIKit location of the touch is passed on the receivers, will the locations be converted to nodeSpace before handing them on for v.3.0?

Apologies in case I'm misunderstood some of the code - I'm just starting to involve with the code base.

If there's agreement that the changes are useful I'm also happy to implement them - the necessary changes seem rather minor.

Fix warnings and optimizations in CCBReader

As we talked about in the "API Documentation with AppleDoc" thread, we should clean up deprecated stuff.
I suggest we:
1)
Remove everything marked as deprecated (I will do that)
2)
Find out what we can not remove in 3.0 for release, and mark it as deprecated
While there will be no alternative right now, people will become aware, that it will change in 3.1. An example would be shaders.
Deprecations should be added in the headers, in the form
-method attribute((deprecated("Shader functionality will change in 3.1")))
And I think we should always add a comment.

Add support for a number of new transitions based on the new shaders.

• glGet* functions are totally missing (they are part of the jsb bindings input file, but they are not generated somehow), makes following impossible:

  * backing up currently bound FBO, VBO, or other state data that may need
    to backed if you use your own GL code (e.g., it is critical that FBO is restored
    on iOS, because there is no EGL) ... ended up using RenderTexture begin-
    end as a side-effect to backup currently bound FBO
  
  * didn't see a way to create a 2nd context either (shared or not shared), so
    couldn't backup the state that way
  

• glVertexAttribPointer is not accepting array format data (only way is through VBO), which makes it worse in the above case as I can't restore VBO binding

• some of the wrapper functions in javascript files have "bufer" in their function parameters, but in functions "buffer" is used (e.g., deleteFramebuffer, some others as well.. just search for "bufer")

I apologize if these have already been fixed, but I have no way in my current development setup to test other version easily. Ignore/reject if these are not valid any longer.

Is there a way to get notified about the scrolling start/end of a CCScrollView (similar to UIScrollViewDelegate)? I couldn't find in the headers of the V3 implementation. If not, are there plans to implemented?

Thanks!

The problem: There are many different color types in Cocos2d and it's hard for a beginner to immediately grasp the differences and when to use which one. Providing a single color class for the public interface would simply this. Another advantage is that the actual implementation can change (maybe it would be more efficient in some case to use ccc4f instead of ccc3b, now this cannot be changed without breaking the API). Sprite Kit uses this approach with the SKColor class.

CCColor would have an interface similar to this:

// Constructors
CCColor* myColor = [CCColor colorWithRed: 1.0 green: 1.0 blue: 1.0];
CCColor* myColor = [CCColor colorWithRed: 1.0 green: 1.0 blue: 1.0 alpha: 1.0];

// Accessing color components
float red = myColor.red;

// Getting data structures for use in GL code
ccColor3B glColorStruct = myColor.ccColor3b;

Implementation: This could be implemented the same way as in SK, by using the native color classes and adding categories to get a unified interface and the extra methods.

#if TARGET_OS_IPHONE
#define CCColor UIColor
#else
#define CCColor NSColor
#endif

Seems to be a little bit broken just now, I'll have a look while I'm in the area.

CCLayer should be renamed to ex CCSpriteSolid
CCNodeMultiplex should probably be placed in a separate file

Class renaming
CCLayerColor -> CCSpriteSolid
CCLayerGradient -> CCSpriteGradient

Update (some) of the Cocos2d tutorials on raywenderlich.com to Cocos2d v 3.

Dirty flag does not work. Initial rendering is not always done. Check CCButton

Support for shaders, including adding more than one shader and applying shaders on the root level (without a specific render buffer).

Shader support should also add an effects node (CCEffectsNode) which support a number of preset effects/filters.

Fix warning on CCLabelBMFont by not using the name property.

New positioning needs to be optimized.

Needs project files for Mac.

OpenGL state manager moved from Cocos3d.

Martin and I will be going over the header files, and update anything we can find.

For now we will coordinate amongst our selves, who is doing what.
If anyone have code they want to document themselves, please let me know.

The Github link early in the README.md file goes to a 404 page:

https://github.com/cocos2d/cocos2d-iphone/tree/gles20

should probably just go to:

https://github.com/cocos2d/cocos2d-iphone

Relevant old tests needs to be converted to new test format.

Some thoughts on new tests:

The old tests uses lots of animations and are fun to watch, but that makes them hard to automate. An idea is to make as many of the tests as possible static and without user interaction. It may be boring to watch, but we could use screen shots to verify that they are working. Naturally, many test are not possible to do in a static way.

New tests should work on both iPhone and iPad.

If possible, someone watching the test should be able to tell if a test is working or failing. A descriptive sub-title of what is supposed to happen is a good practice.

Is anyone using CCLabelAtlas, it seems like legacy and personally I have only used the more flexible CCLabelBMFont.

Anyone be upset if this was retired from v3?

Physics needs to play nicely with SpriteBuilder and position types. This needs to be decided how to go about fixing.

SpriteBuilder & Cocos2d support different position types to layout interface objects, but also to scale up game play for phones vs tablets. This allows users to use the same logical coordinates when doing their game, by just changing the position type to CCPositionTypeScaled their whole game play will work on both phones and tablets. Currently this doesn’t work with the physics and this is something that really need to figure out how to do (physics simulation should be the same on phones and tablets).

I created a very simple sample project to illustrate how the you can use the scaled positions to scale up your gameplay. The physics simulation works perfectly on phones, but is scaled on tablets. I uploaded it to Google drive here (it also includes a compatible version of SpriteBuilder, you can preview in SpriteBuilder and run the Xcode project on iPhone/iPad): https://drive.google.com/file/d/0BzFSRgoEwrfXOWRmc010T2NFRGc/edit?usp=sharing

Currently CCMenu is removed. My understanding is that CCLayout/CCLayoutBox will cover the layout options that CCMenu provided (align vertically, align horizontally). I support that idea, since CCLayout can be used to layout any kind of node not only CCMenuItems.

However, currently CCLayout/CCLayoutBox are not yet part of develop-v3. Will they be added soon?

Currently the AppDelegate class is somewhat complicated, with lots and lots of options for setting up the CCDirector and GLView. I suggest that we create a CCAppDelegate class that contains all code that generally will not be modified by the user and let the user create a sub-class of that class for the configuration. We should also provide a simplified setup method.

By default, only the application:didFinishLaunchingWithOptions: method would be needed to be overridden. It could look something along these lines:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self configureCocos2dWithPixelFormat: kEAGLColorFormatRGB565 screenMode:CCScreenModeFlexible animationInterval:1.0/60];
}

If power users really want to tweak the settings they can just implement the configure method themselves and do whatever they need there.

I'm thinking that we could provide two default 'screen modes', flexible and letter boxed. Flexible is the current default and a letter boxed screen mode would give developers a fixed logical coordinate system that will be scaled to fill the screen but crop off edges on some devices to keep the square aspect ratio.

I suggest that for the fixed size we use a logical coordinate space of 568 x 384 points. This may seem arbitrary, but would make it easy to do letter boxing on all iOS devices while keeping the 1x, 2x and 4x scaling (see picture below).

Templates in V3 are currently not working correctly. What needs to be done to fix them?

Attempting to move this discussion from an email chain. Please excuse the crappy formatting:

Viktor:

I had a look a the latest version of the physics, I know it’s all a work in progress so things may change or are currently being updated. Some thoughts/suggestions:

I cannot find a way to get the area of a physics body (there used to be a property). This seems to be an important feature if you want to create different shapes with the same density – which is a very common use case.
Minor detail: Enumerations should use NS_ENUM (or the Appledoc is unhappy). Also, enumerations and structs should use capital letters, e.g. CCPhysicsBodyType.
It would be very useful to be able to mix actions with physics. To support that, the actions on nodes with physics bodies would need to be run at the fixed time step. (SpriteKit supports this feature)
Is there a need to have kinetic vs static bodies. It would be really cool if this could be handled internally, say if a body hasn’t moved the last time step it is automatically changed to a static type and if you move it it switches to a kinetic type. Would case less confusion for users and be easier to use. (Again, SpriteKit supports this)

Vik

Martin:

I agree with mixing actions, in my own game (v2) it would have been quite handy to occasionally use actions to overwrite the physics movement in CCPhysicsSprite.
A dynamic body that becomes inactive will go to sleep anyway?

Me:

• Area: The reason why I took this out is that it’s impossible to know the area of a shape/body until they are added to a physics node. Secondly, I haven’t decided if bodies should be rescaled/skewed when it’s transform changes in a non-rigid way. (Unity does this, and there are annoying downsides, SpriteKit doesn’t do it)
• NS_ENUM: check.
• Actions: There was some discussion about this before. Basically I think we need to create separate actions for physics enabled things. The action needs to know to update the velocity of a body, and realistically it’s only feasible to apply to kinematic bodies. Actions and physics together is a lovely idea, but I’m not convinced that it can ever work quite like people want them to.

SpriteKit doesn’t have a fixed timestep at all, which is very problematic from a physics point of view. Their implementation is to just run everything on the same variable timestep. I suspect that Sprite Kit also doesn’t update the velocity of bodies that it moves, and simply changes their positions. If true, that is exactly the sort of thing that we need to avoid. It’s a spectacular way to break physics.

• Kinematic bodies: Collision shapes attached to static bodies are stored differently than shapes attached to dynamic or kinematic bodies. While they can be moved, if you are doing it every frame it’s much more expensive to do so than using a kinematic body. On the other hand, having a kinematic body that never moves is also more expensive than using a static body. It’s a hint to the system what you are using the body for. If SpriteKit is allowing one to move static Box2D bodies around as if they are kinematic, then there are serious problems associated with that since they are defined to have a velocity of 0.

Viktor:

I’m not convinced having special actions for physics would be the best way to go (not super user friendly – and would be hard to integrate with SpriteBuilder animations), I can see the issue with the velocity though. Why not in the move/rotate actions check if there is a physics body attached to the node and if that is the case also apply the velocity. It should be possible to calculate the velocity from the last time step, but I guess there may be some trickiness to also update any ancestors. This, of course, would require actions that run on nodes with physics bodies to also run on the same fixed time steps.

SpriteKit doesn’t have a fixed timestep at all...

Their implementation may not be the best in this case (haven’t tried it), but they certainly thinks it’s important enough to make a big selling point out of it. Imo, even without applying velocities this seems to be useful in many cases. Maybe this should be a first step towards a better implementation?
I understand the reasoning of having static and kinetic types, which totally makes sense. What I am curious to know is how costly it would be to move from one type to another. It would be pretty easy code-wise to check if a kinematic body hasn’t been moving from the last frame, and in that case turn it into a static body. Likewise if you move a static body, change the type to kinematic.

Old solution is non-arc and depending on retainCount which is super bad because (according to our engineers) it is not thread safe and cannot be made thread safe as it is only meant to be run through the debugger.

Quick and dirty solution: Use CFGetRetainCount to simulate the retainCount method in non-arc implementation. Still may have issues that potentially can cause crashes and unreliable behavior.

Better solution (props to Philippe at Apportable for coming up with this). Use NSCache and observe the retain/releases. Sample/concept code below:

#import <objc/runtime.h>

@interface TextureCache : NSObject
- (void)didRemoveTexture:(NSString *)key;
@end

@interface TextureWatcher : NSObject <NSCacheDelegate> {
    __weak TextureCache *cache;
    NSString *key;
}
@end

@implementation TextureWatcher

- (id)initWithKey:(NSString *)aKey cache:(TextureCache *)aCache
{
    self = [super init];
    if (self)
    {
        key = [aKey copy];
        cache = aCache;
    }
    return self;
}

- (void)dealloc
{
    [cache didRemoveTexture:key];
}

@end

@implementation TextureCache {
    NSCache *_cache;
}

- (id)init
{
    self = [super init];
    if (self)
    {
        _cache = [[NSCache alloc] init];
        [_cache setDelegate:self];
    }
    return self;
}

- (id)textureForKey:(NSString *)key
{
    NSValue *value = [_cache objectForKey:key];
    return [value nonretainedObjectValue];
}

- (void)addTexture:(id)texture forKey:(NSString *)key cost:(NSUInteger)cost
{
    @autoreleasepool {
        NSValue *value = [NSValue valueWithNonretainedObject:texture];
        TextureWatcher *watcher = [[TextureWatcher alloc] initWithKey:key cache:self];
        [_cache setObject:value forKey:key cost:cost];
        static void *watcher_key = &watcher_key;
        objc_setAssociatedObject(texture, &watcher_key, watcher, OBJC_ASSOCIATION_RETAIN);
    }
}

- (void)didRemoveTexture:(NSString *)key
{
    [_cache removeObjectForKey:key];
}

- (void)cache:(NSCache *)cache willEvictObject:(id)obj
{

}

@end

My understanding is, that all Touch Handling will be done by the CCResponderManager in future. Looking at the code it already looks like a great improvement compared to CCTouchDispatcher.

Couple questions:

1. Touch swallowing is not possible at the moment, correct? If I'm correct, will it be implemented for v3.0?

2. If I understand the code correctly, the hit test is hierarchical (deepest children receive touches first), just as in UIKit? I think it would be great to consider the Z-Order for nodes on the same hierarchy level instead of the order they have been added as children.

3. Currently the UIKit location of the touch is passed on the receivers, will the locations be converted to nodeSpace before handing them on for v.3.0?

Apologies in case I'm misunderstood some of the code - I'm just starting to involve with the code base.

If there's agreement that the changes are useful I'm also happy to implement them - the necessary changes seem rather minor.

As we will not be able to finish a new renderer in time for the 3.0 release, this would be a great feature to add.

The idea is that the CCSpriteBatchNode should support not only CCSprite, but also CCNode (not sub-classes thereof). The CCNode's in this case are only used for positioning. This improvement adds more flexibility when creating more complex animations and positioning (e.g. for animations created with SpriteBuilder).

I see 3 options

1. Convert Chipmunk to ARC
2. Include as a static lib ( some will miss the source code )
3. Try to get script to add -fno-objc-arc to the Chipmunk files