cocos2d for iPhone

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

1. 

   Freecloud
   Member

   Hello,

   I'm working on a game that uses path drawing. I'm noticing that, when I draw slowly, I'm able to draw very smooth lines, but when I really draw quickly, the line becomes very jagged.

   Obviously, there aren't as many Touches events triggered when you swipe quickly versus when you swipe slowly. Also, it seems that the "sample rate" of the Touches events decreases when the game is doing something that is CPU intensive.

   My question: is there anyway to increase the "sample rate" of Touch events? Or is this kind of "just the way it is"?

   By the way, to receive Touches events, I'm just using a Layer object that overrides the ccTouchesBegan, ccTouchesMoved and ccTouchesEnded functions.

   Posted 2 years ago #
2. 

   LongJohnnyE
   Member

   Make sure you are using the correct Director that may slow down FPS a bit in your game but increase the amount of touch events you receive. Check the most recent Director.h file for the info, all I remember right now is Fast Director can starve touch events a bit.

   Posted 2 years ago #
3. 

   Freecloud
   Member

   Wow, thanks for your help! I looked into Director.h and here's what I did:

   I changed this line:
   #define DIRECTOR_FASTDIRECTOR_FAST_EVENTS 0

   to:
   #define DIRECTOR_FASTDIRECTOR_FAST_EVENTS 1

   And, as you said, my FPS went down a bit (from around 57 to around 50 give or take), but my Touch Events are more fluid. Now when I draw a line (even very quickly) it appears really smooth. The lower fps doesn't appear to affecting the game play or look and feel since it's still well above 30 fps.

   Thanks for the tip!

   Dan

   Posted 2 years ago #
4. 

   CJ
   Moderator

   Does anyone know how/if it's possible to get this improved event responsiveness using the new DisplayLinkDirector ?

   Posted 2 years ago #
5. 

   thefuzz
   Member

   @CJ after searching through the forums today I've been wondering the same thing. I 'seem' to be getting improved responsiveness by modifying the preMainLoop function of display link director as follows

   BOOL inMainLoop = NO;
   
   -(void) preMainLoop:(id)sender
   {
   	if(inMainLoop)
   		return;
   
   	inMainLoop=YES;
   	while( CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.004f, FALSE) == kCFRunLoopRunHandledSource);
   	[self mainLoop];
   	inMainLoop=NO;
   }

   Posted 1 year ago #
6. 

   CJ
   Moderator

   @thefuzz can you do a quick check/test for me?

   Look at your CCDirector.m file and find the line that has something like this:

   [displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSDefaultRunLoopMode];

   If it is using NSDefaultRunLoopMode change it to NSRunLoopCommonModes like:

   [displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];

   And remove your changes to preMainLoop.

   Let me know if that has a similar effect on your touch smoothness.

   Posted 1 year ago #
7. 

   thefuzz
   Member

   Just tried it out. For my case I couldn't tell any difference between the touch sensitivity when running forMode:NSRunLoopCommonModes vs forMode:NSDefaultRunLoopMode. Both modes yield near 50-60 fps animation but probably only 5 touch detects per second if that.

   My change yielded game fps somewhere between 40-60 (for the same area in game) but the the touches moved detection is smooth, I'd guess at least 30 fps.

   Posted 1 year ago #
8. 

   thefuzz
   Member

   The other thing that split the difference between fps loss and touch sensitivity gain was to throw out rendering of frames I figure the graphics chip wasn't going to render anyway by adding a mainLoop directly to the DisplayLinkDirector:

   - (void) mainLoop
   {
   	/* calculate "global" dt */
   	[self calculateDeltaTime];
   
   	/* tick before glClear: issue #533 */
   	if( ! isPaused_ )
   		[[CCScheduler sharedScheduler] tick: dt];	
   
   	glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
   
   	/* to avoid flickr, nextScene MUST be here: after tick and before draw.
   	 XXX: Which bug is this one. It seems that it can't be reproduced with v0.9 */
   	if( nextScene )
   		[self setNextScene];
   
   	if(dt>1/100.0) {
   		glPushMatrix();
   
   		[self applyLandscape];
   
   		/* draw the scene */
   		[runningScene_ visit];
   		if( displayFPS )
   			[self showFPS];
   
   		glPopMatrix();
   
   		/* swap buffers only makes sense if we aren't already backed up */
   
   		[openGLView_ swapBuffers];
   	}
   }

   Posted 1 year ago #
9. 

   araker
   Moderator

   while( CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.004f, FALSE) == kCFRunLoopRunHandledSource);

   Above line makes sure that the runloop will process (system) events for the time specified. So when the director runs at 60 fps, one frame is 16.667 milliseconds, add 4 ms for processing events and the fps will be around 50. So the behavior you see, is expected. The touch processing resolution would also be around 50, since every frame a fixed amount of time is reserved for processing the touches. Although with a lot of touches at once, 4 ms might not be enough to process them all (improbable, but possible).

   Edit @theFuzz

   Is your dt ever smaller than 1/100 in your code? That would mean you're running on 100 fps or more. It was my understanding that displayLink synchronizes with the refresh rate of the display. So it can't run faster than 60 Hz.

   Posted 1 year ago #
10. 

    thefuzz
    Member

    @araker For some reason on my G1 phone, when I'm about to skip a frame I get these 'short' dts. I can render them If I want to and swap buffers but it appears to only increase the backup and time spent in my profile sleeping trying to flush the buffer.

    So instead of rendering them I figure I might as well just toss them out and use the processing time to catch up on touch / accelerometer events etc. Overall I've gotten both a higher profile reported framerate (mid 50s as opposed to high 40s) and more importantly a higher perceived framerate (single frame as opposed to multiframe studders)

    Posted 1 year ago #
11. 

    araker
    Moderator

    @thefuzz, that's interesting. I didn't know displayLink behaved that way when the mainLoop exceeds its timeframe.

    Posted 1 year ago #
12. 

    jbglenn
    Member

    I am using the DisplayLinkDirector for iPad dev right now. I have 225 CCBitmapFontAtlas' on screen, each touchBegan and touchMoved runs convertTouchToNodeSpace and calculates its position on screen to its position in a 2d array to check an NSObject's state bool, and if isTouched == NO; then it sets isTouched to YES and changes the opacity on the objects delegate which is the CCBitmapFontAtlas. I use the object to hold state information about its delegate for saving/resuming purposes with NSCoding .

    With my 225 CCBitmapFont's on screen and a single wallpaper I am hitting 30FPS in Release build (which hurts). My touch response time is very poor. When I run my finger slowly they all change, when I run fast I skip a bunch, however I'm not convinced it's due to the FPS but to how fast the director is processing my touch events. My lookup and convert code is quite quick.

    Is there a definitive answer to increase touch response time without modifying the Cocos2D source? I keep Cocos2D outside my project and link to it so I can update it easily and would like to keep it that way.

    Suggestions to my methods are welcome as well :)

    Thanks!

    Posted 1 year ago #
13. 

    jbglenn
    Member

    Anybody??

    Posted 1 year ago #
14. 

    araker
    Moderator

    You could try the preMainLoop adjustment of theFuzz, that will give the system more time to process events. If you need more than 0.004f to process all touch events, that could be a indication that your lookup and/or convert code is too heavy.

    You could subclass the director, override setDirectorType, introduce your own type. Then subclass the CCDirectorDisplayLink, override the preMainLoop method. That way you wouldn't need to change the source, but you do have to maintain the code in setDirectorType and preMainLoop. Although the source stays clean, you'll have more work maintaining the code, compared to changing the source where you only need to maintain preMainLoop.

    Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.