In Cocos2d v0.99 there's a class named CCSpriteFrameCache. I can load all the sprite frames
[[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:#"images.plist"];
and then I can use those loaded frames
CCSprite *sprite=[CCSprite spriteWithSpriteFrameName:#"img01.png"];
Now my question is: Do we create a big sprite sheet that will hold every single image that we're going to use for animations? I mean, I thought I'd have several sprite sheets for different animation objects. If this question is answered NO,so that I load each sprite differently, then my second question is how do I refer to a frame in a specific sprite sheet?
Now my question is: Do we create a big sprite sheet that will hold every single image that we're going to use for animations?
yes, or you can have multiple sprite sheets if you have many different frame images...
I mean, I thought I'd have several sprite sheets for different animation objects.
It depends on the size of the resulting sprite sheet. In principle it is convenient to organize the different frames of the same animation within the same sheet, but if your frames occupy, e.g., 600x600, your sprite sheet will occupy the same memory as a 1024x1024 sheet, so you are better off adding some more frames to that same sheet, even if it belogs to a different animation. In general, you can play with the sheet size, as long as both dimensions are a power of 2, you will not have inefficiencies as to memory occupation and you can organize your frames into different sheets if that makes sense to you.
If this question is answered NO,so that I load each sprite differently, then my second question is how do I refer to a frame in a specific sprite sheet?
by the original filename that was composed into the sprite sheet...
hope it helps...
If possible, cram as much images into as few texture atlases as possible. The determining factor is quite often z ordering. If you have two atlases and two sprite batch nodes, then each sprite batch node can only render their sprites on their z order, while the sprites in the other batch node are either always in front or behind.
You do not need to know which texture atlas (sprite sheet) a sprite frame came from. Just reference it by name. If you need to know which texture the frame refers to, check the sprite frame's texture property and compare it with the texture property of the sprite batch node.
Related
I am trying to make sense of batch rendering with sprite atlases in unity.
I got most of the bits cleared. but one thing I'm not sure of is how do the texture atlases are sent to the render pipeline during batching by Unity?
The reason I'm asking this is that I want to know if the following scenario causes a performance drop rather than a performance gain?
Imagine that we have two sprites with different textures.
each sprite is using a 512 by 512 texture.
The sprite atlas contains two textures of both sprites. so the sprite atlas is 1024 by 1024 (lets ignore the padding for simplicity)
So during the batch draw call, at this point, I PRESUME Unity would be sending the texture atlas along with the other information such as position UV cords etc about each sprite in a batch to the rendering pipeline.
My question is let's assume that the unity couldn't batch them together. what happens then? Would unity now would be sending sprite Atlas which is 1024 by 1024 in size to the rendering pipeline twice? one for sprite A and another one for sprite B draw calls?
One last question - I've been informed that sprite atlases can DECREASE startup time slightly. I haven't found more information about this online and I want to make sure I'm not chasing some myth. is this correct?
In my 2D app, I create many gameObjects with UI image components (I work with new UI). These are simple colored circles. They are placed in different positions on screen. But when I play long enough, the count of these gameObjects becomes too high and it impacts performance.
I thought since these objects are just textures (I do not need them to be animated or something, just simple textures that stay on the same place in the screen all the time), maybe there is a way to merge them into one gameObject with Image component that would hold all these circles in one texture?
I tried to capture the camera view through RenderTexture ReadPixels method, but it captures the whole screen and all objects in it, while I need to merge only these circles and in a specific rectangle on the screen.
What I mean different is inefficient when the game runs.
sprite sheet:
put multiple files in one texture file, and import it to unity, I only import one texture.
sprite packer:
import multiple files in unity, then use the sprite packer to pack it into one texture.
So what is the difference between them? which one is better for sprite animation?
thank you!
In terms of frame rate you will have little to no effect. However in terms of memory, you may see an effect because the sprite packer will be able to deal better with animations that have flexible size.
With sprite sheets, Im assuming you mean atlases that are made up of fixed sized cells. There is no problem with this approach, unless your animation varies dramatically in size, making it necessary to increase the overall cell size to cover the area of the largest animation frame. You would end up having huge amounts of 'empty' and thus wasted space. This is bad since on mobile memory will be your problem.
In general sprite sheets are ok for animations that fit into an efficient cell size, like animated characters:
With the unity sprite packer you wont have this problem, since it will 'pack' the wasted empty space together and create an optimal atlas, hence the name 'packer'.
You can see that in the documentation:
The explosion (or whatever it is) is clearly using optimal space. In a sprite sheet, you would be having to create cells the size of the largest explosion.
In terms of programming ease, using sprite packer you may have to add a bit of code to correct for the original sprite size, so the animation will run smoothly at the 'anchor point'. With sprite sheets, you avoid this by having the fixed cell size.
How does one create the game "area" for a scroller game?
How does one then put various obstacles with collision detection along this scrolled environment.
I want to try out a project which will allow the user to scroll to a certain direction in order to progress through the game.
How does one map the objects within the environment and then move what I guess is the "camera", the view of the environment.
Thanks
The trick is that there is no "area". The only bits that exist are what's under the camera (the view you currently see) and a small surrounding area giving you time to prepare more world in the direction you are moving..
Your world coordinates need to be defined as do the starting coordinates for the view. You use tiles to create the view - at its simplest that is 9 tiles, one you are currently "on" and one in each direction. If you look at the keyboard numberpad you are "on" the 5. If you move a little to the top right you are displaying parts of tiles 8, 9, 5 & 6. At that point you would create new tiles in case you move further. As you leave tile 5 you would probably release tiles 4, 1 & 2. Nine tiles may not be the optimal number of course.
If doing this with UIViews (probably not the high-performance choice) you are probably going to define one big view that can handle all the tiles and tile them onto the view (add and remove subviews), setting the large view's frame to define your camera position. As you move you change the frame to move your camera, when you need to shuffle tiles you move both the tiles and the frame to recenter giving room to move further within the coordinates of your view.
Collision detection is pretty simple since you define your own dimensions (the thing representing "you" in this world) and objects in your view have dimensions you can check against. CGRectIntersectsRect might be the simplest function to use but if you have irregularly-sized views it will get more complicated.
This answer about implementing a cyclic UIScrollView is a similar idea but it only handles scrolling on one direction.
This is a pretty common topic and if you google you will find a lot of sample code and tutorials around.
From the game logic side:
All your objects (lets call them gameobjects) should have a coordinate (x and y position) in your game world. You will keep all your gameobjects in a list. Your player object will be a gameobject too. Usually your "camera" position will be relative to your player objects position. I.e. the player will always be in the center of the screen. To determine the current "screen" position of your objects you will just subtract the camera position from your objects "world" position. Collision is usually made with simple rectangular overlap checks. You give all your objects a width and a height attribute and do your collision checks using x, y, width and height.
From the display side:
If you want to display many objects (i.e. Player, Enemies, Obstacles and so on) the best way to implement something like this is to use an OpenGL View. In this view you can display all Objects as Textures that are mapped to Polygons. You can use a library such as cocos2d which already has all of the code to achieve this easily.
I am learning cocos2d and that we have multiple layers in single scene.
I want to manage both layers at a time I.e, first scene with 480X320 image and second one also with same size. when I try the second one is only visible. Thats ok. But whenever touch occurs I want to add another sprite to both of the layers (different sprites for each). Could any one help with this.
Thanks
Why are you using multiple layers? Layers are for grouping multiple objects so that you can apply effects like movement to all nodes of the layer.
It sounds to me as if you should just be adding sprites to one layer. And if you add two sprites at fullscreen size, one will be on top of the other regardless unless it has transparent parts in the image.