I am using Cocos2D to draw in frustum mode in 3D, therefore I need to access and manipulate the quad_.bl.vertices etc. in CCSprites that are drawn using the CCSpriteSheet.

I have subclassed the CCSprite and overridden the updateTransform method to do this, but as stated before in fast dispatch dynamic access does not work and my approach can not be used. One solution I can think of is to override the CCSpriteSheet draw method to do a normal dynamic function call for updating the transform to its children.

I know that the engine is for 2D and therefore my reasons are not totally kosher, however I am of the opinion that the updateTransform method should be overridable when using CCSpriteSheet.

@CJ: thanks for the info

Did anyone spotted this article on Cocoa with Love:

http://cocoawithlove.com/2009/11/performance-tests-replacing-core-data.html

I am not cocos2d code expert so I don't know how much cocos2d relies on accessor methods, but if it does, maybe this article can help gaining some speeds...

@riq: I took some time and made a test, and my hunch was correct...
If you create an implementation function from a base class and run it against a subclass it actually only calls the base class' method.

So, in the CocosNode example above, this won't work as expected if a subclass of CocosNode happens to override visit...

+(void) initialize {
    visitSEL = @selector(visit);
    visitCALL = (visitIMP)[CocosNode instanceMethodForSelector:visitSEL];
}

Because now every type of CocosNode would be called by the same visitCALL() which is actually the root CocosNode's implementation of visit.

To get around this, each class needs to keep a unique visitCALL.
Well, ok, maybe just add the + (void) initialize{} to every subclass too and store the visitCall as a Class property (not an instance property).
But, since you would still have to access the class from inside CocosNode's visit to get the visitCALL specific to each subclass of CocosNode, would this added request on each iteration outweigh the performance benefit of this whole idea?

This kind of thing is probably a bit safer in places like the scheduler, timer, and touch dispatcher etc...

@CJ: I don't know the answer. The patch creates the "impMethod" at class initialization time.
And if the patch works as you said, then the "impMethod" should be created just before entering the loop.

Does this properly handle subclasses?

for example... If you have CCSprite, but keep the impMethod and selector from CCNode's visit, and at calltime you do impMethod(aSprite...);

Does it call CCSprite's potentially overridden method of visit?
Or does it actually call the CCSprite's super class (CCNode) implementation?

@riq

Just attached the Fast Dispatching updates to r622 - This is based on the trunk checked out at 1PM EST 10/15/2009

I looked at the Particle code and am not sure where Fast Dispatching could be applied, if you can give me some direction I would be happy to patch.

@m2281:
Could add attach the patch in this issue ? thanks.
http://code.google.com/p/cocos2d-iphone/issues/detail?id=622

thanks

@riq

This is tested code, for fast dispatching when method is known, keep in mind the scheduler will be different, I need to look at the code.

EDIT: Also just did the Timer and Scheduler, funny thing was Timer in 8.2 does already this for -tick, but scheduler calls -fire on timer without fast dispatching, I have both done if you want them. I do like the IMP, SEL, and CALL suffixes.

CocosNode.m

typedef void (*visitIMP)(id, SEL);
static visitIMP visitCALL;
static SEL visitSEL;

+(void) initialize {
    visitSEL = @selector(visit);
    visitCALL = (visitIMP)[CocosNode instanceMethodForSelector:visitSEL];
}

CocosNode.m -(void)visit

-(void) visit
{
	if (!visible)
		return;

	glPushMatrix();

	if ( grid && grid.active) {
		[grid beforeDraw];
		[self transformAncestors];
	}

	[self transform];

	for (CocosNode * child in children) {
		if ( child.zOrder < 0 )
			//[child visit];
			visitCALL(child, visitSEL);
		else
			break;
	}

	[self draw];

	for (CocosNode * child in children) {
		if ( child.zOrder >= 0 )
			//[child visit];
			visitCALL(child, visitSEL);
	}

	if ( grid && grid.active)
		[grid afterDraw:self.camera];

	glPopMatrix();
}

@riq

Could you list a few of the methods you think would benefit from fast dispatching? I believe I have a nice clean way to implement and would like to test.

There are essentially two flavors, one where the call is known at compile time example CocosNode draw, and another where it is not, example scheduler.

@onedayitwillmake

Both linked lists and array enumeration could benefit, because the optimization is about calling a method. The objective-c way, uses the dispatcher which has overhead, the example above bypasses the dispatcher, so when calling the same method many times, you see a performance boost.

With linked list it would depend on how they are implemented, make sure you setup the call pointer outside of the loop and only execute the call inside the loop.

I did read the article it's a really good one actually, good link :)

I was asking because in regards to a physics step - you're really letting physics engine, direct who does what when aren't you?

I mean I suppose I am, i run through the box2d bodies linked list, and grab the corresponding cocosnode and do something with it. I was just trying to picture what kind of usage scenario you had in mind regarding physics engine integration.

Me not get usage case, me dumb

@onedayitwillmake

This is more about bypassing the dispatcher in tight loops, however any time you are doing alot of dispatching it should help, see the referenced article.

In regards to a physics engine, is this faster than a linked list?

@riq

I will be using something very similar to this in the TouchDispatcher im working on, I kinda like setting up the C signatures ahead of time so they can be reused (I also like the syntax). If defining them as static causes a problem I will let you know.

static void (*ccTouchBegan)(id, SEL, UITouch*, UIEvent*);

Just tested this, and it works like a champ

typedef void (*ccTouchBegan)(id, SEL, UITouch*, UIEvent*);

I think this would be handy for the physics engine / cocos2d integration, since you are doing a lot of calls similar calls to many objective c objects constantly. I'm no expert though....

@m2281: yes, I think that trick can be applied in some parts of the code.

http://code.google.com/p/cocos2d-iphone/issues/detail?id=622

Cool stuff!
It reminds me of the usefulness of good old c function pointers. :D
I never thought of the benefits of using in tight loops.

I'm glad I caught sight of this sweet info.
Thanks M2281!

@edisonslabs
That's a good question.

For c function pointers to work with c++ member functions you'd have to supply the correct namespace/classname of the function in question.

void (Bar::*ptrToFunc)(int);

Now for objective c? .... With dynamically typed references.... umm

*Shrugs shoulder*

I really should look that up =/

Or....

edisonslab and I would appreciate any answers to the question!

Wow nice tip, I was wondering whether something like this existed.

Though the immediate question that pops up into my mind is what happens for objects that are inherited from MyNSObject? Does it call its super class (MyNSObject)'s method, or does it call the derived class's method (if its overridden)?

Just finished reading the site, and seeing that the performance is comparable to just basic C is mind boggling (well I guess it should have been expected). If your game is loop intensive, this could provide an enormous performance boost.

I was researching fast enumeration, very efficient BTW, and stumbled across this article, about bypassing dispatching when making calls during enumeration. It could also apply to high frequency dispatching. You basically grab the method address and bypass dynamic dispatching.

http://www.formconstant.net/diagrams/?p=40&preview=true

void (*doSomething)(id, SEL);
SEL doSomethingSel = @selector(doSomething);
doSomething = (void (*)(id, SEL))[MyNSObject instanceMethodForSelector:doSomethingSel];

for(MyNSObject *obj in nsArray) {
   doSomething(obj, doSomethingSel);
 }