performance tweaks? « cocos2d for iPhone

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

performance tweaks?

(10 posts) (6 voices)

Started 2 years ago by byron
Latest reply from byron

Tags:

cheap monster beats by dr dre

byron
Member

I have a few questions regarding performance that i was hoping someone may be able to answer or how i could go about finding out performance differences within xcode??

regarding children that get used frequently throughout a layer (or the program) is it better to create a variable with retain property for the child and simply call the variable to make adjustments.. child.position = ccp(10,10);

or use getChild method each time you use it in each method.. like the following:

CCSpriteSheet *sheet = (CCSpriteSheet*)[self getChildByTag:kSheetTag];
CCSprite *child = (CCSprite*)[sheet getChildByTag:kChildTag];
child.position = ccp(10,10);

storing the tags in an enum. The latter is how i have gone about it.. may be a bit more typing but im assuming its better for performance.

Also regarding updating a Label.. I have a DataManager Singleton that stores a value for the score which changes with certain events. i could simply have in my step method something like the following:

NSString *scoreString = [NSString stringWithFormat:@"%d",(int)datamgr.score];
[scoreLabel setString:scoreString];

but this sets the score every time step is called.

I have a HudLayer which displays the score label.. when an event that alters the score occurs my GameLayer makes a method call to its delegate (GameScene) "updateScoreBy:(int)amount" then in turn tells HudLayer to setString of the scoreLabel.

A bit long winded but is this substantially better for performance or am i wasting time and typing too much??

also.. i have tried to make a call to my layers parent (The GameScene) instead of declaring it as the layers delegate.. but i cant seem to get it to works.. is this even possible if so How?

thanks for your time in advance
Byron

Posted 2 years ago #
CJ
Moderator

Keeping references to child nodes will outperform a getChildByTag for sure.

The way I setup my HUD elements is that I have my "datamgr" send out a notification that the score has changed and then the hud would internally mark itself as dirty. Then in a scheduled selector the hud updates its display if it's dirty.

Posted 2 years ago #
Karl
Member

getChildByTag does a sequential search of all children of that node, which gives (n^2) performance. Keeping a reference involves no lookup whatsoever, so it's much faster.
Any time you're in doubt as to which implementation will perform better, look at the source. If you don't have the source, write a test app.

As far as the rest of it goes, you're better off designing a proper architecture to start with, and leaving the optimizations till later. The high score display will account for less than 1% of your game's overall performance, so any optimizations you do there won't even be noticeable.

The big killer on iPhone is texture data. The more sprites or the bigger the textures, the lower your performance. Also bear in mind that texture dimensions always get extended to a power of 2, so a 65x128 sprite performs FAR worse than a 64x128 sprite, which in turn performs exactly the same as a 63x128 sprite.

As for overall performance of the architecture, use event systems for infrequently changing things, and polling systems for frequently changing things (as in things that change every 1-2 frames or more often).

Posted 2 years ago #
byron
Member

ok. thanks for the feedback.. it was my understanding that textures would be the biggest performance drain, so i have kept to one sprite sheet.

but thanks very much for confirmation of keeping references. it makes far more sense now. as i was thinking in terms of memory being around for the duration of the program as apposed to lookup..

One more question.. do you use instruments or any other performance tools? i was intending to take the time at the end of creating a program to study the instruments quite thoroughly.. are they an invaluable tool or a bit overrated?

By

Posted 2 years ago #
David994A
Member

Can anyone explain why PVRTC images perform better than regular old PNG images?

Posted 2 years ago #
CJ
Moderator

Instruments is your friend. Go get to know it.

Once your game is working, get your program onto the device and load up Instruments (there are many to choose from, and the OpenGL preset is a good starter).

Posted 2 years ago #
Codemattic
Moderator

Because the compression format can be expanded using hardware acceleration and it will take up less texture memory. Its lossy so you suffer image quality. PNG's compression algorithm is lossless, and will only reduce your game's file size and not the amount of texture memory they use.

Posted 2 years ago #
Karl
Member

Instruments is a good all around code analyzer. Also, for performance analysis nothing beats Shark.

Here's a quick tutorial: http://developer.apple.com/tools/shark_optimize.html

And for static code analysis, CLANG is your friend.

Tutorial: http://www.fruitstandsoftware.com/blog/2008/08/finding-memory-leaks-with-the-llvmclang-static-analyzer/

Note: Ignore the part about code signing. Don't touch the code signing settings on your project because it'll render you unable to deploy to a real device, and you can't fix it without hacking the project file.

For textures, ALL images (except PVRTC) get loaded into a 32-bit RGBA buffer, then the data gets converted realtime to whatever format you specified. 16-bit formats have double the performance of 32-bit formats. The GL hardware in iPhone doesn't support any 8-bit formats (other than a masking format). PNG has no 16-bit mode; only 8-bit indexed and 32-bit RGBA, so save all your images in 32-bit and have cocos load them in 16-bit if possible (or convert them to PVRTC).

PVRTC gives you 4bpp and 2bpp textures, which are VERY fast, but it's a lossy compression. It works best with images that don't have straight lines or sharp edges (line art files and character sprites look horrible in PVRTC, but photographs look great).
Also, PVRTC works in chunks of 4 pixels, interpolated with an adjacent set of 4 pixels, so the 4 pixels along the edge of a PVRTC image will always look funny. You basically need to make your source image 8 pixels wider and 8 pixels taller, and then offset the sprite or the texture coordinates so that those ugly pixels don't show.
PVRTC images must also be square and a power-of-2 dimension. Regular textures can be rectangular, but must still have dimensions that are a power of 2 (cocos2d automatically converts images to the nearest power-of-2 when you load an image).

No texture in iPhone may be greater than 1024x1024. Cocos will automatically scale an image down if it's bigger (and it'll look awful). If you load a PVRTC image that's too big, it will overwrite the memory of another texture.

In short, take full control over your images early in the toolchain, because the default behavior of the various loaders and image handlers will ruin your day otherwise.

Posted 2 years ago #
mhussa
Member

A big clue to the performance of PVRTC images is the number of bits per pixel, 4bpp to represent 32bpp data so thats 1/8 of the data needed to process per pixel. The storage format of the data means that although its compressed, 4x4 pixel data blocks can be accessed randomly. The PVR data gets decompressed and rendered in realtime by the hardware.

PVRTC doesn't work too well with transparent edges, you end up with edged/halo type artifacts. Fully opaque background images are worth experimenting with though.

Posted 2 years ago #
byron
Member

Thanks again Karl and CJ! some great information there.. and thanks for the tutorials for shark and clang..

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.