Cocos2d：使用CCSpriteBatchNode的6个疑问

Question

我想知道如何优化CCSpriteBatchNode的用法。 换句话说，我理解：

• 1）每个CCSpriteBatchNode实例执行一次对draw方法的调用，从而减少了OpenGL调用，从而显着提高了性能
• 2）每个CCSpriteBatchNode只能引用一个纹理图集

我不确定100％，请问您的答案是：

• 3）如果我有一个纹理图集，例如game-art-hd.png，并在各个类中创建了几个CCSpriteBatchNode，我会得到多个绘制调用吗？ 换句话说，我假设CCSpriteBatchNode的每个实例都将调用其自己的draw方法，从而导致进行多个GL绘图调用，并且比具有一个共享的批处理节点的性能要差。 我对吗？

  -4）如果我在Sprite上使用由多个帧组成的动画，我想应该将动画帧添加到Sprite批处理节点中。 我该怎么办？

  以下是有关我通常如何为子画面设置动画的代码段。 可以注意到，没有将子画面帧添加到子画面批处理节点。 为了获得更好的性能，我可能应该在初始化时执行此操作。 这个对吗？

    NSMutableArray* frames = [[NSMutableArray alloc]initWithCapacity:2]; for (int i = 0; i < 4; i++) { NSString*bulletFrame = [NSString stringWithFormat:@"animation-%i.png", i]; CCSpriteFrame* frame = [[CCSpriteFrameCache sharedSpriteFrameCache]spriteFrameByName:bulletFrame]; [frames addObject:frame]; } CCAnimation* anim = [CCAnimation animationWithFrames:frames delay:0.1f]; CCAnimate* animate = [CCAnimate actionWithAnimation:anim]; CCRepeatForever* repeat = [CCRepeatForever actionWithAction:animate]; [self runAction:repeat]; } 

• 5）部分引用4.是否确定最好避免在运行时将sprite添加到sprite批处理节点或从中删除sprite？

• 6）CCSpriteBatchNode将仅考虑将visible设置为true的sprite还是实际位于屏幕区域之外的sprite？

---

关于3的其他考虑

为了满足我在3.中的假设并减少CCSpriteBatchNode实例的数量，我的解决方案将遵循@Suboptimus在此答案中提出的建议。 我喜欢建议的初始化类的方法，这些类希望与MainScene类共享同一批处理节点，而不是让它们通过self.parent.parent。（...）。parent.finallysharedbatchNode访问MainScene

其他人则建议通过使用self.parent ..... parent并正确转换它来引用MainScene。

就软件工程而言，这也是最好的方法吗？

我更喜欢通过使用对MainScene类的显式引用来明确将sprites添加到何处。如果我在团队中工作或更改类层次结构，这应该会有所帮助。 但是，这样做的缺点是，如果我想向批处理节点中添加后续的精灵，则“需要”存储对该引用的引用，从而导致需要维护更多代码。

我问这个问题的原因是，如果在我的传统“软件工程”思想和“ Cocos2d父节点”层次结构方法之间发现一点冲突。 我是游戏编程的新手，我想了解大型团队中经验丰富的游戏开发人员所使用的方法是:)。 H

Answer 1

1. 正确，但是“绘制调用”并不等同于执行draw方法。 绘制调用是OpenGL状态的更改，需要执行昂贵的操作才能重置状态机。 绑定新纹理或更改变换可以满足要求。
2. 正确。
3. 正确。
4. 没必要那样做。 动画在精灵上运行。 因此，只有精灵需要进行批处理。 如果一个动画帧不是来自同一纹理图集，则当动画尝试使用这样的帧时，CCSpriteBatchNode会抱怨。
5. 更好 在CCSpriteBatchNode中添加/删除精灵比添加/删除任何其他节点要昂贵。 因为精灵批处理节点的四边形需要更新。 但是，如果您有许多子节点并频繁添加/删除，则可能只会有所不同。
6. 不，不。 在这里查看我的答案 。

关于3的其他注意事项：

如果场景层次不太深，则有时可以使用self.parent或self.parent.parent，但仅在父/父关系实际上固定的情况下（即，从批处理的sprite依次绕过sprite批处理节点）以获得基础的“真实”父级）。 但是我不建议更深入。 请参阅我的答案，了解有关self.parent和避免保留周期的技术。

self.parent.parent.(…).parent在于，如果您需要更改父子关系，例如通过在层次结构中添加或删除父节点，这会完全中断。 然后，这将在EXC_BAD_ACCESS中严重崩溃，并且很难调试，因为您将必须检查每个父对象和父对象的父对象，以查看其实际是哪种对象。 访问超过3个或更多层次结构的父级，我不会认为是不好的做法。 这是一种可怕的做法 。

就个人而言，为了访问共享的Sprite批处理等常用节点，我更喜欢这样的解决方案：“ MainScene”在活动时变为临时的Singleton类。 然后，您可以从任何子节点执行以下操作：

CCSpriteBatchNode* mainBatch = [MainScene sharedMainScene].spriteBatchNode;

要创建此临时单例：

static MainScene* instance;
-(id) init
{
    self = [super init];
    if (self)
    {
        instance = self;
    }
    return self;
}
-(void) dealloc
{
    instance = nil;
}
-(MainScene*) sharedMainScene
{
    NSAssert(instance, @"MainScene is not initialized!");
    return instance;
}

与实际单例的区别在于，如果实例不存在，则不初始化实例。 因此，sharedMainScene中的NSAssert。 您仅应在场景实例已经运行时访问它，即，该实例只能由该特定场景的子节点使用。

此半单例允许访问场景的所有属性。 您还可以发送场景可以中继到其他节点的消息。 或将需要移除但无法在碰撞处理过程中移除的物理对象排队到场景中。

而且，如果那个单身汉打扰您，那么总有可能从导演那里获得现场表演：

MainScene* mainScene = (MainScene*)[CCDirector sharedDirector].runningScene;

仅当runningScene确实是MainScene对象时，才应谨慎转换到MainScene。 isKindOfClass：按顺序检查或断言。