cocos2d for iPhone

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

1. 

   Karl
   Member

   I'm in the early design stage for a game that will involve a number of sprites running around the screen. The game requires a slightly up-tilted isometric view, which is always a challenge in a 2d environment.

   Specifically, I'm trying to figure out the best way to handle z-ordering.
   Since I'm using AtlasSprites, I have a caching system setup for the AtlasSpriteManager. Each sprite of a particular type uses a common AtlasSpriteManager, but this is going to be problematic in the real world, since that means that all sprites of a kind will share the z-order of the common AtlasSpriteManager.
   Will it be inefficient if I make a separate AtlasSpriteManager for each sprite?
   If so, is there a way to make multiple sprite managers that share a common texture (as opposed to each sprite manager loading its own copy of the same thing)?
   If not, would making one HUGE texture of all possible sprites be advisable? It would fill memory up pretty quick. If the texture took up more than half the memory, would the PNG loader code choke?

   Also, dealing with Z-ordering in an isometric view, what would be an efficient way to handle z-ordering based on how far "forward" a sprite is? Basically, the closer to the bottom of the screen a sprite is, the higher priority it must have.

   Posted 2 years ago #
2. 

   javy
   Member

   You can change the z order of each individual sprite (or any cocos node) added to a layer, not just managers.

   You could sort the sprites based on it's y position, then change the sprites z-order - but I've no idea what kind of performance hit you'll take doing that.

   Posted 2 years ago #
3. 

   Karl
   Member

   Hmm... What about messing with vertexZ?

   If I were to set the background's vertexZ to 1, and then have all sprites update their z position based on how far towards the top they were (going from 0 to 1), would that work?

   Posted 2 years ago #
4. 

   exorcyze
   Member

   Couple of thoughts :

   Typically with any tiled map, you'd ideally want to have all the tiles for a given map in a single sprite atlas. From my understanding, cocos should also work most effeciently this way. This would also give you more freedom to deal with the z-ordering issue.

   For nice z-ordering, there are a couple of different methods that I think can work fairly well. The easiest to implement is looping through all the tiles that are visible to set the ordering starting in the back corner. Work in rows and go in reverse order. So if your left corner of your iso projection would be the top left of a 2d projection and the top would be your top-right, then work from the top-right to top-left, then down to the next row. Hope that makes sense.

   That approach could end up being slow if you have a ton of tiles visible at once. If that's the case, you could typically have a container for each of the rows, then you have less looping to do as things change. This however requires a bit more code to implement and would obviously be a bit less discoverable to someone who didn't understand what you were doing if they were trying to maintain it. =)

   Just my thoughts, hope they help.

   Posted 2 years ago #
5. 

   Karl
   Member

   Actually no sorry I didn't explain myself properly.

   The play area is a static image that takes up the entire screen. It has been pre-rendered as an isometric projection, so there are no tiles.

   The problem I have is with the sprites that are going to move around in this playfield.

   Posted 2 years ago #
6. 

   jonathan0382
   Member

   If you want to reorder ALL the sprites according to their vertical position then they need to have the same parent / sprite manager, else the layer will go through all the sprites in the first manager, then move onto the next manager and go through its children, and so on.

   HTH

   jonathan0382

   Posted 2 years ago #
7. 

   Karl
   Member

   Ok, after going through the cocos2d source code I think I understand what's going on (please correct me if I'm wrong).

   Atlas Sprites run faster because all atlas sprites associated with a particular sprite manager are drawn together in the same GL call. So if I were to create one sprite manager per atlas sprite, I'd basically eliminate any speed advantages over a regular sprite.

   But since I need all sprites to be able to be drawn over or under any other sprite, my only options would be to have fully independent sprites (regular sprites, or one sprite manager per atlas sprite), or all atlas sprites associated with a single sprite manager (and one HUGE sprite atlas!)

   Since I have many different sprite types with lots of animations, I don't think a huge atlas would be feasible.

   I thought about making my own sprite manager, containing multiple texture maps, but I'm not confident that this kind of solution would perform better than standard sprites in the end, since I'd end up with a separate series of GL calls per sprite.

   This leaves me with using regular sprites so that I can control the drawing order for ALL sprites.

   Any thoughts on this? Have I missed something?

   Posted 2 years ago #
8. 

   exorcyze
   Member

   It would be ideal if spriteAtlasManager was a *property* of an AtlasSprite instead of a parent - then you could reuse the texture it loaded while being able to handle indexing easily without an extra layer in the mix.

   That said, I think you could use the TextureMgr class to handle loading each texture only once ( it's a singleton ) and use that with the AtlasSpriteManager to maximize reuse of textures. You'd have some additional overhead of a manager sitting between the base layer and the sprites but I'm not sure how significant that would be.

   You could then either position the sprites within their respective manager or just position the manager itself ( each one having just a single atlas sprite ). Z ordering would only need to be set for the managers, so it may be easiest to just position the managers x/y as well.

   If it was me, I would probably look into creating a wrapper class for them or a factory ( or both ) that would help simplify the logic and amount of code that would need to happen in the game layer for creation, tracking, etc.

   One final thought - it's entirely possible that AtlasSpriteManager already uses TextureMgr under the hood so that you only have a single texture created for a given atlas graphic. I'd have to dig into the source to find out though, and I'm at work! If you get a chance to I'd love to know if that's the case or not.

   * EDIT * Checking the documentation real quick, it states that AtlasSpriteManager does indeed use TextureMgr when you use initWithFile ( reference ). So that's good news!

   Hope that helps =)

   Posted 2 years ago #
9. 

   Karl
   Member

   With AtlasSpriteManager, all AtlasSprites share access to a single texture atlas.

   The sprite manager begins by calling updatePosition on all its children (dirty ones anyway).
   Each child then does a series of transformations as per rotation, scaling and such, then calls:
   [textureAtlas_ updateQuad:&quad_ atIndex:atlasIndex_];

   Once that's done, AtlasSpriteManager sets up a few things in GL and calls:
   [textureAtlas_ drawQuads];

   The texture atlas then fires out everything at once:
   glBindTexture(GL_TEXTURE_2D, [texture_ name]);

   int offset = (int)quads_;

   // vertex
   int diff = offsetof( ccV3F_C4B_T2F, vertices);
   glVertexPointer(3, GL_FLOAT, kPointSize, (void*) (offset + diff) );

   // color
   diff = offsetof( ccV3F_C4B_T2F, colors);
   glColorPointer(4, GL_UNSIGNED_BYTE, kPointSize, (void*)(offset + diff));

   // tex coords
   diff = offsetof( ccV3F_C4B_T2F, texCoords);
   glTexCoordPointer(2, GL_FLOAT, kPointSize, (void*)(offset + diff));

   glDrawElements(GL_TRIANGLES, n*6, GL_UNSIGNED_SHORT, indices);

   So basically the speed of AtlasSprite comes from the fact that they all get rendered in a single GL operation, rather than each one separately. The downside to this approach is that you can't do this if you have many different spritesheets that must be rendered from with varying z-priority.

   I've been looking around and found the followind discussion regarding z-ordering at the GL level: http://groups.google.com/group/cocos2d-iphone-discuss/browse_thread/thread/d38b8ba0f7d0da7e

   From that, it looks like OpenGL ES is a little braindead and won't render properly if you have transparency. When I tried fiddling with vertexZ in cocos2d 0.82, it only resulted in the sprite appearing smaller (because it was further away), but for some reason it STILL got rendered over top of a sprite that was "closer"... Go figure.

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.