Static background image causing big FPS drop

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

Static background image causing big FPS drop

(51 posts) (9 voices)

Started 1 year ago by dolor
Latest reply from araker

Tags:

dolor
Member

Here's the code. I hope the comments clarify it enough. If not, i apologize; My English isn't great, but my explanation skills are simply terrible. I've also uploaded part of a screenshot of the app to illustrate what i mean with cloud 'layers' (in this example i'm using 3 different depth layers): http://imageshack.us/photo/my-images/812/layerample.png/
The info button on top-left shows the UIScrollView i was talking about, which allows me to edit constants which alter the clouds' behaviour to easily test in-app what looks best. That way my designer can more easily find that out; Since i'm barely creative, it generally works out better if he tests that ;)

#import "CloudLayer.h"
#import "RDCloud.h"

@implementation CloudLayer

//Some 'constants' i can edit from a UIScrollView within the app to alter the clouds' //behaviour. That way i can edit some number without having to rebuild each time.

@synthesize speedModifier;
//The speed with which the clouds move
@synthesize numberOfClouds;
//Total amount of clouds
@synthesize numberOfLayers;
//Amount of depth layers the clouds are distributed amongst
@synthesize scale;
//How much longer the most distant layer is than the closest
@synthesize totalCloudHeight;
//Total difference of height between the closest and furthest layer.
@synthesize increments;
//Amount with which each cloud's location increases compared to the previous.

- (id)init
{
    self = [super init];
    if (self) {

        cloudsArray = [[NSMutableArray alloc]init]; //The array used to hold the clouds

//The loop i'm using to give the clouds different images. Currently 3 different, though
//it's designed for more different images.
        int s = 0;
        for (int i=0; i<30; i++) {
            CCTexture2D *cloudImage;
            switch (s) {
                case 0:
                    cloudImage = [[CCTextureCache sharedTextureCache]addImage:@"Cloud1.png"];
                    break;
                case 1:
                    cloudImage = [[CCTextureCache sharedTextureCache]addImage:@"Cloud2.png"];
                    break;
                case 2:
                    cloudImage = [[CCTextureCache sharedTextureCache]addImage:@"Cloud3.png"];
                    break;

                default:
                    break;
            }
            RDCloud *cloud = [RDCloud spriteWithTexture:cloudImage];
//RDCloud is my CCSprite subclass
            [cloud setOpacity:0];
            [self addChild:cloud];
            [cloudsArray addObject:cloud];
            s++;
            if (s>2)
            {
                s=0;
            }
        }

        [self schedule:@selector(tick:)];
    }

    return self;
}

- (void)tick:(ccTime)dt
{
    cloudPosition += speedModifier * dt * 0.03f;
//CloudPosition is the one point moving along the line.

    int partDifference = ((scale * 620) - 620) / numberOfLayers;
    //How much longer each layer's line is compared to the previous one
    int totalLength = (numberOfLayers/2) * (numberOfLayers-1) * partDifference+numberOfLayers*620;
    //totalLength: all the layers added to each other
    if (cloudPosition > totalLength) {
        cloudPosition = 0;
    }
    else if (cloudPosition < 0)
    {
        cloudPosition = totalLength;
    }

    for (int i=0; i<numberOfClouds; i++) {
        RDCloud *cloud = [cloudsArray objectAtIndex:i];

        int cloudLayer = 0;
        double newPos = cloudPosition+increments*totalLength*i;

        while (newPos>totalLength) {
            newPos -= totalLength;
        }

            for (int p = 0; p < numberOfLayers+1; p++) {
	//Loop to determine in which 'layer' this particular cloud is.
                if (newPos<(620+((p+1)/2*p*partDifference)+p*620)) {
                    if (p>0) {
                        double correction = (620+(double)(p*partDifference));
                        newPos = (newPos-(620+(p/2)*(p-1)*partDifference+(p-1)*620));
                        newPos = newPos/correction;
                        newPos = newPos * 620 ;
                    }
                    cloudLayer = p;
                    posDone = true;
                    break;
                }
            }

        [cloud setRDScale:1/((scale-1)/(double)numberOfLayers*cloudLayer+1)];
        [self reorderChild:cloud z:numberOfLayers-cloudLayer];
        double cloudHeight = 430-((totalCloudHeight)*2/numberOfLayers)*cloudLayer;
        [cloud setPosition:CGPointMake(newPos-150*cloud.scale, cloudHeight)];
    }
}

@end

Posted 12 months ago #

araker
Moderator

@dolar, you can see all your previous posts if you click on member below your picture.

Yes you can scale, rotate sprites of a batchnode independently. All images that are loaded are put in the textureCache automatically. The effect you're going for is called parallax scrolling, cocos has a class for that by the way (CCParallaxNode).

When a sprite is added to a batchnode, the batchnode takes care of the drawing, so the draw method of the sprite isn't called anymore (and you shouldn't call it manually either).

It seems there is something very wrong with your code, if adding only one cloud drops the fps that much. What happens when you add the cloud to the layer directly, without using your whole system?

Edit, this was a reaction to your previous post.

After glaring over the code, I see that you're setting the opacity of the clouds to 0, this will still draw them. It's more efficient to set the visibility to NO.

Posted 12 months ago #
dolor
Member

Adding just one cloud directly to the scene and placing it in the middle of the sky gives me a slightly unstable 60fps. A problem in the code for the clouds was the very first thing i thought of, but the 'tick' code takes a fraction of a second and last time i tried, even when i didn't schedule it the code was this slow (actually, i scheduled it and unscheduled on the first tick so the clouds would be in position).

I'm also glad to hear that it is possible. But somehow, i still got the error saying that i shouldn't call draw, which i never did. The only time in my objective-c programming career (which now spans a stunning 1 year) i in fact touched the draw class was recently, when i tried to blur out some of the clouds in the back (which did not work by the way), and i removed that part of the draw code.

Edit: Hm, i was not aware of the difference. I thought setting visible to NO was just another way of doing it. Since i'm occasionally fading in/out some of the clouds though, i'll be needing at least part of this code. I'll see if i can call [cloud setVisible:NO] after the fading is done.

Also, why didn't i know about that parallax node before? It looks like almost exactly what i needed, though it took me about 3 days to make up the full calculation now ;) Though my calculation probably has a few more things it can do.

Posted 12 months ago #
araker
Moderator

That warning is a indication the a sprite which is associated to a batchnode (property usesBatchNode), is drawn on its own. Most probably you're adding a sprite initialized with a batchnode to a layer/scene and should have added it to the batchnode.

Posted 12 months ago #
dolor
Member

That's what i supposed but i am quite sure i added them all to the batch. I'm going to retry it now, let's see if it helps anything.
Also, is it possible the problem has to do with transparent parts in my png? Not that there's much i can do about those though, but still.
Lastly: I edited the code to set the cloud's visible property to NO if the opacity is 0. This indeed helps with the lag if there are less clouds displayed, but with all clouds on screen it still lags as much.

Posted 12 months ago #
araker
Moderator

The transparent parts in your clouds won't help. Displaying around 30 clouds would mean a lot of overdraw. There is something you can do about it, rendering a textured filled polygon. Physics editor does this for you, as well as this free project.

I'm not sure if you already tried this, but you should place all the cloud sprite in one sheet, instead of rendering 30 separate clouds. Reducing the number of draw calls is one of the best methods to improve performance, especially on older devices.

Posted 12 months ago #

dolor
Member

So basically, that means drawing polygons instead of rects? I'm currently trying again to add them to a CCSpriteBatchNode, but i still have that same error: "If CCSprite is being rendered by CCSpriteBatchNode, CCSprite#draw SHOULD NOT be called". This is how i'm adding the clouds:

CCSpriteBatchNode *cloudBatch = [CCSpriteBatchNode batchNodeWithFile:@"CloudSpritesheet.png"];
        [self addChild:cloudBatch];
        cloudsArray = [[NSMutableArray alloc]init];
        int s = 0;
        for (int i=0; i<30; i++) {
            CGRect cloudRect;
            switch (s) {
                case 0:
                    cloudRect = CGRectMake(0, 0, 256, 128);
                    break;
                case 1:
                    cloudRect = CGRectMake(0, 128, 256, 128);
                    break;
                case 2:
                    cloudRect = CGRectMake(0, 256, 256, 128);
                    break;

                default:
                    break;
            }
            RDCloud *cloud = [RDCloud spriteWithBatchNode:cloudBatch rect:cloudRect];
            [cloud setOpacity:0];
            [cloudBatch addChild:cloud];
            [cloudsArray addObject:cloud];
            s++;
            if (s>2)
            {
                s=0;
            }
        }

How can i find out why the draw is called? I checked all the classes related to RDCloud, but its parent is never changed. So either i'm missing something out or i'm just using CCSpriteBatchNode completely wrong.

As to the link you posted: If i get it right, it's to make a mask for the texture? Can you use that and the spritebatch together? EDIT: Ok, nevermind, someone already asked that on there. So i'll first try out the spritebatch to see if that will help enough. I guess it will eventually be less of a hassle if i get it working.

Posted 12 months ago #

araker
Moderator

This code looks very normal, the problem must be elsewhere. Can you post the RDCloud source as well, or at least all the initialize methods?

Posted 12 months ago #

dolor
Member

I doubt there's anything weird in there. The only reason i subclassed it was for some of the behaviour of the rain that comes out of the clouds. Here's the code:
As a side note, RD is the abbreviation of my app's development name, but i guess you found that out ;)

#import "RDCloud.h"
#import "RDParticleRain.h"

@implementation RDCloud

@synthesize rainSystem;
@synthesize precipicationAmount;

- (id)init
{
    self = [super init];
    if (self) {
        rainSystem = [[RDParticleRain node]retain];
    }
    return self;
}

- (void)setRDScale:(float)newScale
{
    if (newScale!=self.scale) {
        if ([rainSystem active]) {
            [rainSystem stopSystem];
            [rainSystem setAutoRemoveOnFinish:YES];
            [rainSystem release];
            rainSystem = nil;
            rainSystem = [[RDParticleRain node]retain];
            [self setPrecipicationType:precipicationType];
            [self setPrecipicationAmount:precipicationAmount];
        }
        [self setScale:newScale];
    }
}

- (void)setPrecipicationAmount:(int)newPrecipicationAmount
{
    precipicationAmount = newPrecipicationAmount;
    [rainSystem setEmissionRate:precipicationAmount*self.scale];
}

@end

I thought it had something to do with rainSystem, but i cant find anywhere where im adding it as a child. RainSystem is a subclass of CCParticleRain, with a customized init method to set some of the values, like speed, gravity, texture etc. I got another layer which handles the rain and checks the system of each cloud every step; if it doesnt have a parent it adds it to itself, and positions it right under the cloud. The 'setRDScale' method is just meant to solve a little bug i had with the rain; If a cloud moves off the side of the screen, it re-enters on the other side on the next layer. Therefore, the scale was changed, also of all the drops that were still falling.

Here's the code for the precipicationLayer:

#import "PrecipicationLayer.h"
#import "CloudLayer.h"
#import "RDCloud.h"

@implementation PrecipicationLayer
@synthesize cloudLayer;
- (id)init
{
    self = [super init];
    if (self)
    {
            [self schedule:@selector(tick:)];
    }
return self;
}

- (void)setPrecipication:(double)precipicationAmount
{
    for (RDCloud *cloud in [cloudLayer cloudLocations])
    {
        [cloud setPrecipicationAmount:precipicationAmount];
    }
}

- (void)tick:(ccTime *)dt
{
    NSMutableArray *positions = [cloudLayer cloudLocations];
    for (RDCloud *cloud in positions)
    {
        CGPoint pos = [cloud position];
        [cloud rainSystem].position = ccp(pos.x, pos.y);
	//Move the particleSystem so it's centered under the cloud.
        [cloud rainSystem].visible = [cloud opacity]==255;
	//Make the particleSystem invisible of the cloud is invisible, or becoming invisible

//if the particleSystem does not have a parent, it was newly made due to a changed scale, so add it as a child to this layer.
        if (![[cloud rainSystem] parent]) {
            [self addChild:[cloud rainSystem]];
        }
    }
}

@end

Posted 12 months ago #

abitofcode
Moderator

At the moment there are too many varying factors. Try isolating the problem.

My first attempt would be to create a spritesheet containing the clouds and then in a new project just keep adding clouds randomly to the screen to see at what point you get a slowdown. You could also create a version that doesn't batch the clouds for comparison.

Posted 12 months ago #
dolor
Member

This is already the test environment; If i'm trying to isolate something i just dont add the other layers ;) due to that, we came to the conclusion that the problem was probably drawing a large number of clouds with quite big transparent bits over a big background. The combination of those two seemed to trigger it; no background, no lag or no clouds, no lag. I'll be trying to add the whole batch directly to the scene for comparing, so i at least know if i'm doing the batching wrong altogether or that it's another factor. The code I've posted so far is most of this test app though; It's a relatively small part within the real application.

I'll be trying to add it directly to the scene tomorrow; right now i need some sleep. Good night people, and thanks a lot for the help so far :)

Posted 12 months ago #
dolor
Member

Ok, somehow i got it to work now. No idea what caused the error in the first place but it works. 42-50 FPS, so still not much of an improvement. I'll try to get the mask thingy to work.

Posted 12 months ago #
dolor
Member

Hm. Apparently my CCParticleSystems eat tons of memory (uncommenting the parts that have to do with those makes my memory usage go from 24 MB to 46 MB), and the part that re-allocs them when the scale changes leaks like hell (about 20 MB per minute). Guess i'll have to fix that first. Strange thing is that instruments doesn't detect the leak...

Posted 12 months ago #
dolor
Member

I hope you're still reading this topic after all my bumpy posts ;)

I was wondering; if i use a batchnode to 'clip out' the bottom part of my background, which i am sure is always covered, will that help a lot? I have 3 layers of backgrounds overlaying each other at the bottom, which causes a big overdraw i guess. So i was wondering if i could just clip it out with a batchnode or if i had to ask my designer to remove a part of his beloved background ;)

Posted 12 months ago #
araker
Moderator

No problem, it never hurts to help ;) (according to eek the cat).

One thing that can also help is to turn blending off for your background layers (if they don't have transparent parts),

[sprite setBlendFunc:(ccBlendFunc) {GL_ONE,GL_ZERO}];

If the backgrounds are drawn with a batchnode you can only define one clipping rectangle (and use glScissor) in the draw method of the batchNode. Even though you're going to insult your artist, I would crop the background texture, then you can save memory as well as having less overdraw.

Posted 12 months ago #
dolor
Member

Thanks :) crop it out in the draw method or in the image itself? Since i didnt think you'd save memory cropping it in the draw event. Turning off blending sounds good too :) also: if you load a ccsprite with a batchnode, does it load that part of the spritesheet seperately? So do i need to make the seperate parts of the sheet (say, bottom and top half of a background) powers of 2?

Posted 12 months ago #
araker
Moderator

I mean cropping as in making the png smaller by removing that part of your background that isn't visible at all due to all the layers. The same goes for using spritesheets. The images on a spritesheet don't have to be powers of 2, the whole sheet is loaded and you're only referencing to parts of the already loaded image data.

Posted 11 months ago #
itlgames
Moderator

Hi @dolor, did you managed to sort your problem? I run into a similar issue:

http://www.cocos2d-iphone.org/forum/topic/17736

And also tried few of the things suggested on the forum with no luck. To me it only happens on the retina devices, on an iPod 1st gen run smoothly 60fps. If I remove my background I also get the 60 fps on retina. I was going to use the CCBackgroundSprite suggested as well, not sure if that may make any difference. I'm using rc2 1.0.0 reorder sprite branch.

Posted 11 months ago #
MisterX
Member

I also have multiple background images and encountered bad frame rates. The solution for me was to minimize draw calls. Batch as much as possible in a single call. I have one sprite sheet that contains all background elements and game elements. My goal is to draw everything in only 2 calls. One call for the game elements and background images, and a second for the UI elements (all in their own separate batch). Two batchnode draw calls per game cycle and that is it.

This results in 58 to 60 fps no matter what happens on screen (on a 1st Gen iPad).. I'm still working on my game but my tests, thus far, show that it works. When you have a bunch of different CCLayers, each with different batches, and a few more draw calls added in the mix for this in that, the frame rate becomes abysmal if you have rather large textures involved.

Posted 11 months ago #
bcichowlas
Member

Also on the iPad, I am considering having the static background drawn using Cocoa/Interface Builder and then doing my cocos2d animation things with a transparent background (perhaps simply by setting the CCLayer opacity to false). I am wondering whether this would give me better performance on the device and whether it would help me avoid bad performance and bad fps readings on the simulator.

Or is it all just equivalent in the end, since the hardware ends up doing the same thing anyhow? Or do I get some inherent benefits there since I can put my background on a shared sprite sheet?

More complicated to think about than I thought.

Posted 9 months ago #
araker
Moderator

@bcichowlas, you won't get better performance that way. Using multiple rendering systems, cocos uses OpenGL, your UIView UIKit or Core Animation, interferes with each other. Also you'll get additional blending costs because you're using a transparent full screen view on top of the background.

Posted 9 months ago #

RSS feed for this topic

« Previous 12

Reply

You must log in to post.