On Mon, Oct 28, 2013 at 2:15 PM, Mikolaj <[email protected]> wrote:
> I debated posting my code to google code to show this in context, but I'm > not sure it's necessary. > > ... > The idea being that walls are always on top of floors when creating > tiles. However, sometimes they are in reverse, the 'walls' gets in a lower > level than 'floors'. It's never random or changing or anything like that > within one instance of the program, but under some circumstances the order > is reversed. Can this be explained by some peculiarity of BatchNode? Other > than that I do not see any logical reason why the script would behave like > this. > > Another approach is to patch cocos an Ninteroc mentions in this thread: http://thread.gmane.org/gmane.comp.python.cocos2d.user/1686 If this works for you, and performance compares well with your two-batchs workaround, then cocos should incorporate that patch. > I fixed it by separating the batch nodes: > > self.floor_tiles = BatchNode() > self.wall_tiles = BatchNode() > > # ... > > if attribute == 'floors': > self.floor_tiles.add(tile, name=cell.__id__) > > elif attribute == 'walls': > self.wall_tiles.add(tile, name=cell.__id__) > > I'm haven't tested whether this will impact performance for large maps. > > Any ideas what may cause the original bug behaviour? > > Any reason to prefer fewer batches to more? > > I remember long time ago someone telling in pyglet list that 'a lot' of batches will degrade performance. With only a few batches it is probably a matter of doing some performance tests, using your real data. -- You received this message because you are subscribed to the Google Groups "cocos2d discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/cocos-discuss. For more options, visit https://groups.google.com/groups/opt_out.
