AtlasSprite « cocos2d for iPhone

cocos2d for iPhone » Programming » cocos2d support (graphics engine)

AtlasSprite

(20 posts) (8 voices)

Started 2 years ago by natedood
Latest reply from napierzaza

Tags:

natedood
Member

Is it correct that an atlas sprite manager can only have one defined sprite sheet?

Or is it possible to add other atlas sprites to the same sprite manager?

The reason I'm asking is that I would like the sprites to sometimes overlap each other by z-index, but the z-index of the sprites can change dynamically.

For example, I have a top down view of a level, when a moving char passes behind something, I want their char to appear to be behind the object, however, when they are in front of it, I want them to appear in front of the object.

This seems doable (by re-calculating the moving char's z-index as it moves up or down on Y axis) IF your char is on the same atlas manager since the z-index between the moving and non moving char will be in relation to each other.

The problem lies in that the moving chars will be on a different sprite sheet than the sheet with the objects.

Is the only way around this to put the chars and objects on the same sheet or manager?

Here is an image that may help clarify : http://dev.webclarity.com/guru/z-prob.jpg

Let me know If I'm not being clear enough on my description.

Any guidance you can provide is greatly appreciated!

Posted 2 years ago #
Joao Caxaria
Member

How I did that was to add 2 different atlas sprite managers that point to the same texture, each in a different Z and just switch between them. Not pretty but it worked..

Posted 2 years ago #
natedood
Member

Wouldn't that double the number of sprites? I may not be understanding you correctly.

Or would it be intensive to have my char sandwiched between two atlas sprite managers, and then swap the sprites between the two (keeping sprites with a Y higher than my char on the back, and sprites with a lower on the Y on the manager in front)?

Of course this creates new problems if there are more than one "char" types that need to be overlapped on the screen at one time.

I really wish i could just add them all to a regular layer, but from what i understand i would have to use normal sprites which would be much less efficient (although, I won't be updating the sprites on screen, but will be moving the layer they're on).

Posted 2 years ago #
natedood
Member

Or is there perhaps some way to define an objects z-index in relation to *everything* being drawn on the screen regardless of the layer (or atlas manager) that it is sitting on?

I'm guessing no - that the parent object's z-index overrides it, which makes perfect sense, but that would also solve my problem if I could have one atlas sprite and manager, and have another manager whose sprites would appear above and below the other.

Any ideas?

Posted 2 years ago #
natedood
Member

trying to embed image :

Posted 2 years ago #
Joao Caxaria
Member

From your image, I really don't know how to do it except from adding 5 TextureAtlasManager's. Try moving the AtlasSprite from Manager to Manager if sprite count is a issue.

I'm hoping someone can come up with a clever solution... :S

Posted 2 years ago #
riq
Key Master
Yes, if one AtlasSpriteManager is not enough to hold all your textures, then you could split it in different AtlasSpriteManagers, and implement a "migration sprite" method.

eg:
```
-(void) migrateSprite:(AtlasSprite*)sprite from:(AtlasSpriteManager*)from to:(AtlasSpriteManager*)to
{
  [sprite retain];
  [from removeChild:sprite];
  [to addChild:sprite z:XXXX];
  [sprite release];
}
```
and all the AtlasSpriteManagers should be children of the same parent, and you should order them according to your needs.
eg:

1st: AtlasSpriteManager with moving characters (z=0)
2nd: AtlasSpriteManager with non moving sprites: columns, etc (z=1)
3rd: AtlasSpriteManager with moving characters again... the same texture as the 1st one. (z=2)

and you should only migrate sprites from the 1st AtlasSpriteManger to the 3rd one and vice-versa.
Posted 2 years ago #
natedood
Member

The main problem with that is that often a sprite will actually overlap some non moving sprites, while be underneath others (like the middle char in the exmaple graphic).

Since there can be hundreds of these little objects on a map, it would involve creating a ton of managers (which may be just fine, but seems like it wouldn't be).

Is there any advantage to using an atlas sprite if the texture is not going to change dynamically (after initially set on screen)? they wont move, but the layer containing them will (scolling the map etc).

It would be so incredibly easy to just have all the assets on a layer (with a z in relation to their perspective, so bottom column has a higher Z than the middle, middle column has a higher Z than the top one, etc), and just change the moving char's z-index to the Y of their location. Then all of the overlap "just works"

Let me know on the sprite item above - i really don't want to take a massive performance hit obviously with sprites - but i'm unclear on when the atlas sprite is more efficient.

Posted 2 years ago #
Clain
Member

This is a very interesting problem. I've been trying to figure out how this was done in 16-bit consoles RPG/adventure games (Final Fantasy, Seiken Densetsu, Zelda to name a few) but I don't even know what API developers had to draw on screen. For example, in Secret of Mana, you can walk behind trees :

More impressive, you can walk in the vegetation, with your body covered by the plants and your head above them :

This game was released 16 years ago on a hardware completely outdated by the iPhone and yet...

Is there any advantage to using an atlas sprite if the texture is not going to change dynamically (after initially set on screen)?

Yes, if you draw at least 2 different sprites from the same texture, because the AtlasSpriteManager can draw all its children (AtlasSprites) in as many openGL calls as a regular Sprite would require. See this thread for clarification.

Now, back to the problem. The graphical elements need to be drawn from top to bottom. Here is how I would go about this : I'd first have one AtlasSpriteManager per row (for static background tiles) with z indexes as in natedood's previous picture. Then I'd have one AtlasSpriteManager per movable sprite and change their z indexes according to their y position on the screen. This still would be more efficient than using only regular Sprites. I admit I don't see how I'd make the "vegetation" effect of the above screenshot.

Another solution might be to subclass or create a new class similar to AtlasSpriteManager with convenient methods to reorder the AtlasSprites based on their position in the scene. But you'd have to fully understand how the sprites are handled at the TextureAtlas level if you want to write efficient code which does not hit performance (too much). I have no idea if looping through all the sprites every cycle to eventually reorder them (and thus reorder the quads of the texture atlas) would be too much to take for the iPhone. This solution would require that all the graphics to be displayed (background + moving characters) sit in the same texture. And the 1024x1024 limitation may be a big obstacle.

Posted 2 years ago #
Joao Caxaria
Member

@Clain, throwing a random thought about the implementation of the secret of mana drawing (loved the game btw):

- Drawing the sprites all in the same Z (even the character), from top to bottom?

Posted 2 years ago #
Codemattic
Moderator

"- Drawing the sprites all in the same Z (even the character), from top to bottom? "

sounds right to me!

Posted 2 years ago #
Clain
Member

@Joao and Codemattic :
Yeah, it seems to be the way. I can confirm that because I couldn't help but play a little bit longer and in the first village, I saw a little girl running vertically (back and forth) through a treasure chest and I saw the moment she overlapped the chest and vice versa.

However, I'm still wondering how they did the "vegetation effect" or the "water effect". I took a few screenshots when I was in the water (body in the water, head above the surface), have a look :

I drew blue lines to separate the rows of tiles. I put the character between tiles and the result was perfect every time, the head was never overlapped by a single pixel of water.

Posted 2 years ago #
Codemattic
Moderator

ahh, well Im guessing the sprite isnt one image. The body is drawn, and then the head is drawn on top. You could change the head, expressions, which direction its looking, while keeping the body static. But also it would allow effects like walking under water, where the body is drawn with a blue tint and the head drawn on top. Just a guess.

Oh - and I bet this gets much harder when its an 45 degree iso perspective - as opposed to a head-on camera view!

Posted 2 years ago #
Clain
Member

Some more screenshots :

I'm almost sure the character is drawn in one unique sprite. You can see when he prepares an attack with a knee on the ground that half his head is under water. And you can also see when he's facing north his head and shoulders are above the surface. The water is definitely on a different layer with alpha (you can even see the wavelets animation on top of the character's pants). I'd like to know how they managed to get part of the sprite under water and part of it above without involving tiles. Same thing with the cauldron, except the transparent water is a red opaque potion.

I guess these effects have to be applied at the pixels level (I don't see how it could be done with tiles only). If that's the case, then VBO is the (only ?) way to do it in cocos.

Posted 2 years ago #
natedood
Member

They way I've decided to implement the grassy texture issue is when the chars are over a certain texture, they're switched to a sprite that has semi-transparent legs, letting the below texture seep through. May not be the best way to handle it, but seems to work and look okay.

Still puzzled on the overlapping stuff. I think I may just have to keep an atlas of the chars on the map elements atlas png. It's just far too simple not to approach it that way. I'm also planning on there being multiple layers of atlas sprites (background tiles, shadows, background (roads etc - no overlapping needed), objects (must overlap)

I decided to write my own mapping engine and an editor tool (which is still a WIP) - but so far its looking reasonably promising. For now, my NPC's will just have to have paths that don't require overlapping - but the player will be able to without problem, so hopefully it will work out - players might not even notice. =)

Here is a little pic of the generator so far - likely to change in the near future, but you'll kind of get the idea of how I'm trying to lay things out. All of the elements and their properties get stuffed into sqlite tables to be called up and drawn on load. It might not be the most elegant, but I like it (and level updates can be done over the net easily using the same assets etc). If I can ever get it all done and anyone is interested, I'll release the tool.

Posted 2 years ago #
pplgreg
Member

The map editor looks great so far. I would be very interested in taking a look at it when you are done.

Posted 2 years ago #
Blue Ether
Member

SNES uses very specific hardware methods for moving and organizing graphic data. Yes it is very old, but it was also HIGHLY OPTIMIZED, particularly for the kind of games that were prevelent at the time. It doesn't work anything like OpenGL, so you shouldn't be surprised to find some things are easier and some things are more difficult to replicate.

Having had some experience with Nintendo DS development, it wouldn't surprise me at all if the character sprites were actually two seperate sprites that move together. but it isn't necessary either. The sprite's data isn't stored in textures, it just sits in a particular "sprite" area of the VRAM. VRAM is very limited though, and of course since SNES games were chip-based, copying to and from the main memory of the game is not very expensive. Sprite memory is quite limited, and I can guarantee you that only one frame of animation per character was stored in memory at a time. So every time the animation frame changes, new data is copied into VRAM. By the same token, it is possible to manipulate that data while it is being copied.

Short answer is: don't try to extrapolate about the performance characteristics of systems like SNES, GBA, NDS, etc based on knowledge of OpenGL or cocos2D.

On a hardware note, the SNES had very limited z-layers for tile data. Many "character by the object" effects were actually performed using a masking object rather than by using any real z-depth management. I can't speak for Secret of Mana in particular with this regard.

My advice for you is not to look at your map as consisting of objects, but simply stick to tile data, and seperate the trees, columns, etc so that their bottom parts are in a sprite manager below the moving characters and their top parts are above them. This requires careful map design, using bouncing boxes to make sure characters don't wander into a place where their body gets cut off magically at the seam. But guess what- the SNES game you're holding up as an example does exactly that! There is trickery afoot. ;-)

Posted 2 years ago #
Clain
Member

@Blue Ether :
Thank you for your very very interesting post. You're right, we can't compare the rendering techniques of such different systems. I'm still wondering how to make a water effect (like the one in Secret of Mana) with cocos. I don't need it for my game, but someday I'd like to take a closer look at this problem.

You're right about separating the sprites into several layers, this technique has been posted a short while ago on this forum : http://www.cocos2d-iphone.org/forum/topic/1378#post-8302

Posted 2 years ago #
natedood
Member

The main problem with using multiple layers and moving the sprites between them is that you can't gracefully increase the number of char sprites without increasing the number of layers and ultimately a whole lot of complexity. So to do the example of the 3 chars and two columns, you would need 5 layers. That number of layers would increase by 1 for every additional char you added, i.e. numlayers = 2 + numchars. The handling code for a dynamic number of chars would quickly become quite ridiculous.

I wish there was some way to have a global z-index draw order that can span among many atlas sprites, that would solve the problem.

Posted 2 years ago #
napierzaza
Member

The more I think about it the worse it gets. I think this is a make-or-break feature for many different game types. If this isn't possible on cocos2D than it really undermines its usefulness. I don't need to say it, but many other libraries have this option, I noticed that the Torque 2d engine is able to do it.

PS: I realize it's 700$.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.