cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   M2281
   Member

   Perhaps I have missed something here, but I believe we can eliminate the locks on the CCSingletons. This can be done everywhere singletons are used in CC.

   Replace This:
   

   +(CCTouchDispatcher*) sharedDispatcher
   {
   	@synchronized(self) {
   		if (sharedDispatcher == nil)
   			sharedDispatcher = [[self alloc] init];
   	}
   	return sharedDispatcher;
   }

   With This:
   

   + (void)initialize {
       if (self == [CCTouchDispatcher class]) {
           sharedDispatcher = [[self alloc] init];
       }
   }
   
   + (CCTouchDispatcher*)sharedDispatcher {
       return sharedDispatcher;
   }

   I would also love a way to plugin other implementations on singletons, for example CCTouchDispatcher, this doesn't solve that issue, but it does eliminate the locks.

   Posted 2 years ago #
2. 

   riq
   Key Master

   yes, cocos2d isn't multithreaded, so the lock can be avoided.
   Do you know if with this change we will gain performance ?

   Posted 2 years ago #
3. 

   M2281
   Member

   @riq

   +(void)initialize is the key here, it will only be called once on one thread and will be called prior to any instance of the singleton being referenced from any thread, eliminating the need for locks on sharedDispatcher etc.

   Locks are a performance bottleneck, but the real question is normally are the singleton classes thread safe, where you would be using locks on collections and such, those locks cannot be avoided.

   Any thoughts on being able to replace some of the shared classes, I did a new CCTouchDispatcher, but plugging it in was rather painful?

   Posted 2 years ago #
4. 

   riq
   Key Master

   @m2281: Do you mean this thread:
   http://www.cocos2d-iphone.org/forum/topic/2981 ?

   Before changing anything I would like to understand what are the issues that you are trying to solve.
   Are you trying to improve the performance ? or a have better API ? I'm a bit confused about that thread.
   If you are trying to improve the performance, how many FPS are we gaining with the proposed patch ?

   I know that there some [copy] methods that can be avoided on the TouchDispacher...

   Posted 2 years ago #
5. 

   M2281
   Member

   @riq

   The issue is the ability to plug in a new touch dispatcher. I am porting over a touch dispatcher used in another non CC app, not saying it has to be part of CC would just like to plug it in so we don't have to rewrite our touch code.

   Below is code from the director, where touch dispatcher is hard coded to the CCTouchDispatcher class.

   -(BOOL)initOpenGLViewWithView:(UIView *)view withFrame:(CGRect)rect
   {
   
   	// set the touch delegate of the glview to self
   	[openGLView_ setTouchDelegate: [CCTouchDispatcher sharedDispatcher]];

   I already have a hack, to get around this without changing the CC source, and I don't take lightly to altering a framework either, it would just be nice to have a way to set the TouchDispatcher on the Director (which btw should probably be declared as a protocol on the director) I know you are busy on 0.9, was just looking for an opinion.

   Posted 2 years ago #
6. 

   riq
   Key Master

   ah... I understand now.

   I'll think about it... Director has a sort-of "plugins"... you can instantiate any of the 4 possible directors.

   What features does your TouchDispatcher have ?

   Posted 2 years ago #
7. 

   mhussa
   Member

   Sounds like removing @synchronized is a good idea, especially since there's no thread contention.

   The following article shows what it compiles to, so yes you should get a speed improvement.

   http://googlemac.blogspot.com/2006/10/synchronized-swimming.html

   The singleton paradigm is useful in a single-threaded context for single-point of reference problems, or for addressing the static initializer problem (order of static initialization isn't guaranteed across compile units).

   I don't know anything about custom touch dispatchers, I'll leave that to the experts.

   Posted 2 years ago #
8. 

   M2281
   Member

   @riq

   CCX here is for experimental to avoid naming collisions...

   CCXTouchDispatcher has the concept of a CCXTouch which is CCNode aware, similar to the TargetedTouchDelegate, however CCXTouch once claimed is in charge of invoking moved, ended, and canceled, and also has some other sugar to ease touch handling, such as the concept of siblings for multi-touch, scenarios.

   Since the CCXTouch does it's own invocation using IMP, one advantage is the ability to swap invocations, a common use is one method on the delegate to handle a touch ended that has moved and another method to handle a touch ended that has not moved, in which case you update the invocation on the CCXTouch when the touch moves. Sounds complex, but coding against it is simple.

   I plan on sharing this, but for now the issue of plugging it in has proven challenging, and the CCTouchDispatcher should probably be pluggable.

   Posted 2 years ago #
9. 

   rolando
   Moderator

   So... inspired by this thread, I removed all the @synchronize code from cocos2d. After that I build again my main project, with which before removing @sync I was getting ~45-50 fps, and after that, I got the same result :-P
   Even though I use plenty of calls to the shared* methods in my code (in the draw callback of several nodes), I saw almost no improvement of performance...

   Posted 2 years ago #
10. 

    Thomvis
    Member

    Locks are expensive, so in theory the performance should increase, at least on the regular mac os. Apple is advising to replace all lock logic by Grand Central Dispatch calls. It would be great if GCD is added to iPhoneOS!

    Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.