Is it true that AtlasSprites can only be children of AtlasSpriteManager nodes? I'm noticing that mine disappear when I child them to anything else, like a layer, for instance.
Can AtlasSprites be children of any node?
(14 posts) (8 voices)-
Posted 2 years ago #
-
Steve Oldmeadow
AdministratorIf you want them to be drawn then, yes. AtlasSprites don't implement their own drawing. The AtlasSpriteManager does the drawing of all the AtlasSprites it is managing in one hit. This is one reason that it is fast.
Posted 2 years ago # -
Thanks for the prompt reply.
As a followup, what can we do if we want to intermingle the z-orders of atlassprites from 2 different atlasspritemanagers?
Posted 2 years ago # -
Steve Oldmeadow
AdministratorYou can't
Posted 2 years ago # -
shadaz
MemberHello, I asked this similar question in another topic, but it went unanswered. If I have a tilemap with 2 layers - "Ground Layer" and "Tree Layer" (like in the example demo) and I want to draw non-map tiles ie sprites ABOVE the ground but BELOW the Tree layer. How can this be done? What is the best way? I tried playing with Z orders, but it either goes below all the map layers or above all the map layers. This seems like such a common task, thought it would be easier - something I am missing? thanks!
Posted 2 years ago # -
ItchyGames
MemberThis thread talks about the strategy of using two AtlasSpriteManagers on a single AtlasSprite.
http://johnehartzog.com/2009/05/using-cocos2d-atlasspritemanager/While there it is used to have sprites share some common textures but not others; I think this could be used to move an atlas sprite in the z. In the sample below from the thread both managers add the child on z 1 but you could surely give them different z depths.
Later replies in the thread discuss some details of the performance details of multiple sprite managers.
sprite1 = [[AtlasSprite spriteWithRect:CGRectMake (sizeOne.width, sizeOne.height, sizeOne.width, sizeOne.height) spriteManager: [self spriteManager1]] retain]; [[self spriteManager1] addChild:sprite1]; if(![[self spriteManager1] parent]) [[[LevelController sharedSingleton] gameLayer] addChild:[self spriteManager1] z:1]; [sprite1 setVisible:NO]; sprite2 = [[AtlasSprite spriteWithRect:CGRectMake (sizeTwo.width, sizeTwo.height, sizeTwo.width, sizeTwo.height) spriteManager: [self spriteManager2]] retain]; [[self spriteManager2] addChild:sprite2]; if(![[self spriteManager2] parent]) [[[LevelControler sharedSingleton] gameLayer] addChild:[self spriteManager2] z:1]; [sprite2 setVisible:NO];Edit: This thread http://www.cocos2d-iphone.org/forum/topic/1221
also discusses AtlasSprites and Zdepth. But certainly seems to my inexperienced eyes that using sprites would be the better option until you find performance issues, THEN migrate to the multiple manager option.Posted 2 years ago # -
Steve Oldmeadow
Administrator@shadaz - you need to separate out your layers into two different AtlasSpriteManagers, so basically two different maps not one map with two layers. Then order the drawing ground, sprites, trees.
However, if you mean the TMX isometric demo you have big problems as you need to intersperse the drawing of the tree layer with your sprites and you have to order the drawing by the isometric depth - there is no solution for this problem in cocos2d yet. The simplest thing for now would be to treat the trees like non moving characters and include them in the same AtlasSpriteManager as your character sprites which gets drawn after the ground.
Posted 2 years ago # -
Steve Oldmeadow
Administrator@ItchyGames - yes you can have multiple AtlasSpriteManagers to manage different depth levels and move sprites between them. You need to understand the performance implications though and question whether you would just be better off using Sprites.
Things get even more tricky when you throw particles into the equation as they use a totally different batch rendering method so interspersing them with AtlasSprites at different depths will be tricky whereas if you just use Sprites it is straightforward.
Posted 2 years ago # -
shadaz
Member@Steve - Thank you so much for your reply. Yes I am talking about the TMX Iso Demo. I would like to use the Tree layer as a "wall" layer so that the player is blocked by the tile at which the base of the tree but is allowed to walk behind it so that the tree overlaps the player. If this is not possible, it kinda defeats the usefulness of using layers in the map editor.
My initial assumption (hope) was that I can insert an atlas sprite in between the TMX Layer 0 and Layer 1, and check the existence of any tile on layer 1 to determine movement. I dont think there should be an issue with isometric depth if everything is drawn from the top down per layer like the current iso demo. (The trees in the front cover the trees in the back.)
Is this a planned enhancement?
p.s. Sorry to hi-jack this thread, but it involves similar question on how atlas sprites and layers work.
Posted 2 years ago # -
Steve Oldmeadow
Administrator@shadz - from the documentation:
Technical description:
Each layer is created using an TMXLayer (subclass of AtlasSpriteManager). If you have 5 layers, then 5 TMXLayer will be created,
unless the layer visibility is off. In that case, the layer won't be created at all.
You can obtain the layers (TMXLayer objects) at runtime by:
- [map getChildByTag: tag_number]; // 0=1st layer, 1=2nd layer, 2=3rd layer, etc...
- [map layerNamed: name_of_the_layer];so each layer is an AtlasSpriteManager. It still won't fix the problem of mixing character sprites in with the trees. Also the isometric depth is straightforward if everybody has their feet on the ground and the ground level is constant. It can get tricky when things fall, jump or float. You may also need z ordering to handle the situation when multiple sprites are at the same depth, for example a character may have a weapon that should always appear in front of them.
Posted 2 years ago # -
Neantis
MemberFrom this article you may understand how to solve your problem.
http://stendhal.game-host.org/wiki/index.php/HowToUseTiledToCreateStendhalMaps
They use 3 layers ( 0:ground, 1:player 2: over the player)
In the layer 0 they place the tree's roots and the top of the tree (which is always above the player in the layer 2)
Posted 2 years ago # -
Sama7
MemberThis would work great except if you add an atlas sprite to a tmx layer (an ASM) it only supports 1 tilesheet, the one in the map(or on top of tree, 1 per layer), which means you'd have to embed your player/unit sprite sheet INTO the layer (In Tiled, as you are making the map), then add the atlassprite into the TMXLayer and reference the sheet in the layer for your animations. its a PITA.
Which is too bad, otherwise it would be a really easy solution to the z-ordering drawing issues.
Posted 2 years ago # -
bladnman
MemberI'm glad there is a healthy discussion about this. I have a game where my characters need to change depth. So the easier ideas of just creating x-layers doesn't quite cover this.
Say 2 Managers (sheets)
2 Characters from each
I need one character from manager 1 to be in the back and one to be in the front, sandwiching the others (from manager 2). I do see the technical troubles with all of this. And I do know I could duplicate my manager 1 and create 2 of it to solve the trouble. But my real implementation has 50 from every manager and 10 managers... so a memory impossibility to duplicate managers. In fact, the AtlasSpriteManager is exactly WHAT makes my engine perform since I've only pulled each sheet into memory once.What can we do to get nearer a solution for mixing z-depth for manager children? I'd hate to leave it at "Cocos2D can't do that, use another engine".
Posted 2 years ago # -
napierzaza
MemberSo I suppose it's not feasible to create a texture atlas that can include several different textures?
Then you could have a AtlasSprite manager that holds multiple sheets, perhaps by name. Just to be able to organize the z order.
So yes, i appears as if it involves swapping textures which means swapping OpenGL calls so I assume this is now workable.
Posted 2 years ago #
Reply
You must log in to post.