I have an iPad application containing a grid of 400 CCSprites, some of which contain several sprites already layered together.
I have not used CCSpriteBatchNode as I believe the ZOrder needs to be the same for all items in the node, and this isn't the case. Performance is acceptable.
However, I need to optionally overlay a small dot in the centre of each of the 400 sprites (if the user wants a grid displayed to help with layout). The problem is, by adding another CCSprite (using addChild) I now have over 800 sprites on the screen and it's hitting the performance hard.
Is there a way to draw the new sprite onto the one that's already there that doesn't affect performance? (I guess like dynamically generating a new sprite made up of the parts, but that isn't a set of stacked CCSprites)
I'm using Cocos2d V2.3 - I did attempt to convert the project to Cocos2d V3, but found performance slightly worse, and it caused many scaling issues, which, given the project is close to completion, mean it's better to finish this in V2.3.
Many thanks in advance for any suggestions. PS: I found some similar questions but they dealt with how to stack sprites - this isn't a problem, I can do that, it's the drawing a new sprite that I'm struggling with.
Change textures of existing sprites to the textures with the dot.
If this solution doesn't match your case, please supply a screen shot (or part of screen shot), or more detailed description of the sprites on your scene.
The answer comes in the form of CCRenderTexture - draw all the sprites into a a single texture, and then use that for a single CCSprite.
Related
I have a 5 frame run animation for a character on a sprite sheet. I would like to give this character multiple "upgrades", such as sunglasses, hats, etc. I don't know the "correct way" to do this, so here's what I did:
I constructed a layer to represent the sprite itself, and added the character first, then the hat on top. I have a 5 frame animation for where the hat would be on that characters head ALSO on the sprite sheet, and have it animating with the exact same parameters as the main character.
The problem is that when I try to animate the two sprites simultaneously (the character sprite and the hat sprite), they get out of sync. Sometimes it works great, but sometimes the timing is just a wee bit off, which is enough that his head will go through the top of the hat, or the hat will pop off his head every step.
My current solution is to have an update tick, and manually cycle through the frames every time some number of milliseconds has passed, which works, but I assume since I'm manually setting the frames it's using up more processor time than needed.
So what would be the "correct" way to add a hat to a sprite without having to have a "hatted sprite" series on your sprite sheet, and keep them animating together.
edit: sorry this is tagged badly, I apparently don't have a high enough reputation to tag this "cocos2dx", despite the fact that it's a cocos2dx question.
Well if i have the same situation i will go with taking different spritesheets for different animation according to upgrade of character, that way there will be no need for two different animation pluse u can adjust sprites for best effect and it won't interfare with other animation, only problem is u have to make different sprites according to upgrade.
What kind of animation are you using?
I recommend you to animate using an skeleton. This way is very easy to replace any body-part with different sprites. In TestCpp you have some examples of skeleton animation using CocoStudio (free) or Spine (paid). You even have an example of an animation where weapons are replaced.
If you need to stick to standard frame animation, you need to make sure that both animations start from the same frame when you replace anything. Otherwise, if you replace your hat when you are on a keyframe different from 0, the animation will be out of sync. One solution is to restart both animations. The other is to check the current frame of the body animation and force the hat animation to start on that frame.
OK so what I ended up doing, all the sprites that are assembling a larger character object are put together in a class, together with a float "_lastFrameUpdateTick" and int "_lastFrameNumber". in my update(dt) I have a switch case on _lastFrameNumber for each sprite so it knows if the current time tick is past the _lastFrameUpdateTick + that frame's display time, it should update all the sprites in that class to the next frame number (also allowing me to shift around sprites relative position manually, for cases where, say, a character is bouncing up and down on the back of a horse). This does require me to put copies of any hats repeatedly on the sprite sheet for every animation (though that could probably be faked with plist were one so inclined). This also has the added advantage of allowing certain frames to display slightly longer or shorter than others, allow explicit skipping around in animation sequences depending on events (if there's an earthquake and the character is on a leaned-back part of an animation it falls backwards; if it's on the leaned forward frame of an animation it falls forward), and its easy to halt animations while allowing other stuff to keep running. Most importantly is that doing it manually allows me to always know exactly what frame a sprite is on, so it can smoothly transition between animations without hiccups (I know that if i'm leaned back and want to run forward, i need to go through a leaning-forward animation first).
I'm sure there's a better way to do this, but I'm no C++ developer, and it works, so I'm moving on.
I want to know if there is any benefiting caching a sprite sheet and accessing the sprite by frame without using the CCSpriteBatchNode?
In some parts of my game the sprite batch node is useful because there is a lot on the screen, however on another part its not, because there are just a few things, and there are requirements for layers so CCSpriteBatchNode wouldn't be useful. However, for the sake of consistency I would like to use Sprite Sheets for all my sprites, and so was beginning to wonder if I would still receive any benefit from it? (Or worse that it could some how be slower...)
There is defiantly a benefit to putting all your sprites into a texture atlas or sprite sheet as you called it. Textures are stored in memory in power of 2 dimensions. So if you have a sprite that is 129px by 132px it is stored in memory as 256px by 256px which is the nearest power of 2 size. If you have many sprites that is quite a lot of extra memory used up.
By using a texture atlas you only have one texture in memory and then it pulls the pieces out of it that it needs for your sprites. These sprites can be whatever size you want without having to worry about power of 2 sizes.
You can read more details about it on this tutorial
http://www.raywenderlich.com/2361/how-to-create-and-optimize-sprite-sheets-in-cocos2d-with-texture-packer-and-pixel-formats
I'm building a cocos2d game where I use two background sprites, actually one is a sprite, the other one is a CCMask that is used to make holes into the other background, but the performance problem is the same even when using 2 regular background sprites on top of each other.
When I use one background sprite, my FPS is around 60 all the time, when I use two background sprites the FPS drops to 30 every time. I've googled around, tried different solutions including reading sprites from a sprite frame cash instead of from a file, unfortunately the result is the same.
I just can't figure out why this is happening. Does any one here have any idea why this is happening and how to get around it?
On older devices (1st & 2nd generation, ie iPhone 3G) this can easily happen since they have terrible fillrates.
If possible try to SpriteBatch the two background images. You need to add both to a texture atlas, for example with TexturePacker. Sprite batching is particularly effective if the sprites are large.
Also, just in case: don't test performance in the Simulator. Simulator performance has no relation to actual device performance whatsoever.
I have a cocos2d iOS app with Box2D (and Kobold2D); i have an array of 18 CCSprites in a layer. They are now created using spriteWithSpriteFrameName and a textureAtlas (thank you texturePacker). When i want to update the 18 sprites, i think i can either a) change the image (but i am not how to do that -- i saw a reference to setDisplayFrame, but i need to get the image from the batch node / texture atlas using spriteWithSPriteFrameName) or b) destroy the sprite i previously created and added to the layer with addChild and create a new one it it's place (18 sprites, 16 times in one "game"). In terms of resource usage and performance, which method is preferred? Seems like a), but again, not sure how to do that.
thanks
You could add the following code as extension to CCSprite:
-(void) setDisplayFrameNamed:(NSString*)name
{
[self setDisplayFrame:[[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:name]];
}
If you are using box2d you could also use GBox2D
which is described in detail in the MonkeyJump Tutorial
The ideal solution is not to switch textures of a sprite at all if you can avoid it. Second best is changing texture via Spriteframe (note that this rules out the use of a CCSpriteBatchNode).
Creating new sprites is typically the operation which has the highest negative performance impact.
I guess I'll illustrate with an example:
In this game you are able to draw 2D shapes using the mouse and what you draw is rendered to the screen in real-time. I want to know what the best ways are to render this type of drawing using hardware acceleration (OpenGL). I had two ideas:
Create a screen-size texture when drawing is started, update this when drawing, and blit this to the screen
Create a series of line segments to represent the drawing, and render these using either lines or thin polygons
Are there any other ideas? Which of these methods is likely to be best/most efficient/easiest? Any suggestions are welcome.
I love crayon physics (music gets me every time). Great game!
But back to the point... He has created brush sprites that follow your mouse position. He's created a few brushes that account for a little variation. Once the mouse goes down, I imagine he is adding these sprites to a data structure and sending that structure through his drawing and collision functions to loop through. Thus popping out the real-time effect. He is using Simple DirectMedia Layer library, which I give two thumbs up.
I'm pretty sure the second idea is the way to go.
First option if the player draws pure freehand (rather than lines), and what they draw doesn't need to be animated.
Second option if it is animated or is primarily lines. If you do choose this, it seems like you'd need to draw thin polygons rather than regular lines to get any kind of interesting look (as in the crayon example).