CODEWITHSUNDEEP
iosiphonecocos2d-iphonegrand-central-dispatch
James
James

Reputation: 746

errors when trying to use dispatch_async with cocos2d functions

I'm building a scrolling menu that generates new rows of buttons on the fly, and must generate each button from a large number of sprites. Because this is processor intensive, the menu sticks for about a quarter second each time it needs to load a new row of buttons. I realized I needed to add multi-threading so the button load could be handled in a different thread than the scroll animation, but when I do it crashes when it tries to load new buttons. Here is the code I'm using:

-(void)addRowBelow{
    _rowIndex--;
    dispatch_async(dispatch_get_global_queue( DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        NSMutableArray *row = [self addRow:_rowIndex];
        [_buttonGrid addObject:row];
        [self removeRow:[_buttonGrid objectAtIndex:0]];
    });
    _nextRowBelowPos += _rowHeight;
    _nextRowAbovePos += _rowHeight;
}

Each time I test it I get a different error, sometimes it's a memory error or an assertion failure. I suspect it has to do with calling cocos2d functions asynchronously?

Upvotes: 1

Views: 307

Answers (2)

FuzzyBunnySlippers
FuzzyBunnySlippers

Reputation: 3397

You are probably getting crashing issues because you are multithreading access to the cocos managed objects (sprites, layers, nodes, etc). Since the engine expects to use the internals of these objects for display, GPU operations, etc., and is NOT thread safe, you are probably not going to have good outcomes with multi-threading. You may be changing stuff right in the middle of when it is using it.

Creating/destroying sprites on the fly is probably the reason for your slow down. Cocos2d can display lots (I think it is on the order of 2k) objects on the screen at 60 fps...as long as you don't throttle it down by doing a lot of creation/destruction or AI.

I suggest you preload all your sprites before your scene goes on the stage. You can do this in an intro scene or in the init of the scene itself and let the sprites be owned by the scene. Then you can iterate over them during the update() call and change their positions, make the visible/invisible, etc.

For reference, I usually create different "sprite layers" that load up all their sprites on addition to the scene. If I am going to have dynamic objects, I try to allocate some up front and recycle them when possible. This also allows me to control the order of "what is in front of what" on the screen (see example here). Each layer also draws elements of specific "entity types", giving a nice "MVC" character to a lot of the display.

This is analogous to the way iPhone Apps recycle table cells.

Only create them the first time you need them and have a stash on hand before you need them at all.

Was this helpful?

Upvotes: 2

erikprice
erikprice

Reputation: 6308

The pattern you probably want to use is

  1. Dispatch work to a background thread. (Note that the work must be safe to execute on a background thread.)
  2. Dispatch back to the main thread to update your UI.

Here's an example of what that looks like in code:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

    // Do work that is safe to execute in the background.
    // For example, reading images from disk.

    dispatch_async(dispatch_get_main_queue(), ^{

        // Do work here that must execute on the main thread.
        // For example, calling Cocos2D objects' methods.

        NSMutableArray *row = [self addRow:_rowIndex];
        [_buttonGrid addObject:row];
        [self removeRow:[_buttonGrid objectAtIndex:0]];

    });
});

Upvotes: 0

Related Questions