A fast, easy to use, free, and community supported 2D game engine
PJX
Member
On the iPhone, I see no performance hit. I have a 320x480 image I add as z:-100 to the scene. For the iPad, I created a 768x1024 version of it and did the same thing. Either as a CCSprite from a file, or via a CCSpriteSheet, displaying this image as the background knocks performance from 30 FPS down to 15 FPS in the simulator...and that's when nothing is going on.
Is there a better way or is this just a simulator issue (I've seen performance issues mentioned in other threads).
tia, Patrick
I'm testing a theory on iPhone right now, and I'd love feedback from iPad dev's too (since I haven't got the iPad sdk going yet).
What I thought might help is to give GL more triangles per quad to reduce the number of pixels affected by any given tri. Play the the pxPerTile value as a larger value will result in fewer triangles. 32x32 seems ok for iPhone but maybe overkill for iPad so try 64x64 and 128x128 too.
Here's the code:
#import "CCBackgroundSprite.h"
...
CCBackgroundSprite *aSprite = [CCBackgroundSprite spriteWithFile:@"YourFullScreenImage.png"];
[self addChild:aSprite];Save this to CCBackgroundSprite.h
#import "CCSpriteSheet.h"
@interface CCBackgroundSprite : CCSpriteSheet
{
}
+ (id) spriteWithFile:(NSString*)filename;
- (id) initWithFile:(NSString *)filename;
@endSave this to CCBackgroundSprite.m
@implementation CCBackgroundSprite
+(id) spriteWithFile:(NSString*)filename
{
return [[[self alloc] initWithFile:filename] autorelease];
}
- (id) initWithFile:(NSString *)filename
{
CCTexture2D *texture = [[CCTextureCache sharedTextureCache] addImage:filename];
return [self initWithTexture:texture capacity:1];
}
-(id)initWithTexture:(CCTexture2D *)texture capacity:(NSUInteger)capacity
{
CGSize winSize = [[CCDirector sharedDirector] winSize];
NSUInteger pxPerTile = 32;
NSUInteger numRows = (int)ceilf(winSize.height)/pxPerTile;
NSUInteger numCols = (int)ceilf(winSize.width)/pxPerTile;
NSUInteger numTiles = numRows * numCols;
if( (self=[super initWithTexture:texture capacity:numTiles])) {
[self setContentSize:winSize];
self.anchorPoint = CGPointZero;
self.position = CGPointZero;
CGRect texRect = CGRectMake(0, 0, pxPerTile, pxPerTile);
CGPoint tilePos = ccp(0, winSize.height-pxPerTile);
for(uint i=1; i<=numTiles; i++){
CCSprite *aTile = [[CCSprite alloc] initWithTexture:textureAtlas_.texture rect:texRect];
aTile.anchorPoint = CGPointZero;
aTile.position = tilePos;
[self addChild:aTile];
[aTile release];
texRect.origin.x += pxPerTile;
tilePos.x += pxPerTile;
if(i%numCols == 0){
texRect.origin.x = 0;
texRect.origin.y += pxPerTile;
tilePos.x = 0;
tilePos.y -= pxPerTile;
}
}
}
return self;
}
@endin my iPad app I am seeing similar things. Until I get one on april 3rd, I won't know for sure if that's the case on a real device or not. For one, debug vs release I hear makes a big difference as well as the simulator being.. a simulator, not an emulator. It's using OS X's frameworks, not the iPhone OS frameworks, which may have to do different work under the hood.
Is it worth getting Riq to set up a new section in the forum for iPad development? I wanna be able to find these posts in about 3 weeks when I finally get around to some iPad development.
MisterX
Member
From the info I have obtained, the iPad simulator's FPS performance does not reflect the actual FPS performance of the iPad device. If an app is only running at 30 FPS in the sim it most likely will run at 60 FPS on the device. I don't have an iPad yet, of course, but the simulator seems to be significantly slower than the device.
Speed wise, Apple reps have indicated it should have graphics processing power equal to the 3GS iPhone and 2nd Generation 32/64gig iPod Touch. Note that the 2nd Gen 8Gig iPod Touch has INFERIOR speed and cannot run Open GL ES 2.0 apps (I know this because I have one and discovered this little unpleasant surprise today).
@CJ
I put the code in my iPad game. I have full background pngs Just sitting on a page it was 15FPS. With your code it went to 30 solid. But it was all screwed up. If you're interested, I can post a screenshot.
@wiegerthefarmer sure post the screenshot.
Ok I started a new app and just did the following:
' CCSprite *blah = [CCSprite spriteWithFile:@"menu.png"];
[self addChild:blah];
[blah setPosition:ccp(384,512)];'
And it was fluctuating between 25-30fps
When I put in CJ's code I got a solid 20fps which is slower, I also think it depends what you've got running on our mac and what speed your mac is.
Oops. My bad. When I was going to get the screenshot I figured I take a look at the code. In my code I set the position to winsize.width/2,winsize.height/2, because the anchor point was unset (so it must be right in the middle of the image). With your code it sets it all to 0,0, so when i did the half way code, it moved the background to be starting at 1/2 way.
taking out the winsize/2 ended up fixing the problem, and as a result the fps dropped back down too. So it looks like it's more of a issue of just having to take time to draw what's on the screen.
I had the same experience - added a 1024x768 PNG as a background sprite and in the simulator saw the FPS drop from 60 to 20. However when I run on the actual iPad it runs at close to 60... I'm not certain that the numbers are not reflective of a relative change in perf, but at least they are not reflective of the actual perf on the device.
spawrks
Member
I can also verify same issue. I tried MANY different things... including
*running a UIImage layer underneath my opengl layer with transparent clear colors
*changing RBA888848484884 .. all the different versions of loading the image
*PVR texture instead of quality graphics...
*Tiling pieces...
I'm under the impression that while the FPS is great on the device, someone needs to do something about answering whats going on with these large images.
If any cocos dev is here, could someone explain what really is the most optimal approach to background images for 1024x768? I'm under the impression in OpenGL there are ways to specify a draw that will be mainly drawn over with other sprites, but all the documentation for cocos2d suggests that we should just use a CCSprite as our background.
Is this really the best approach for backgrounds or is there a better way? Is there room to create a CCBackground class that is more specific or would it be a waste of time to seriously investigate?
Better yet, is this just a function of the cocos2d code using the device correctly, and the simulator just not emulating well?
Just as a followup - I have experimented more and I can say that there is a real performance difference in adding a background on the physical device. Although it is not as bad as the simulator shows, it is substantial and I'm hoping something that can be corrected.
Steve Oldmeadow
Administrator
Why wouldn't the performance difference be substantial? You've just added over 3/4 of a million more pixels that have to be considered by the GPU. There is no magic.
Maybe people need to get a bit more clever about backgrounds at this resolution. Once cocos2d supports OpenGL ES 2.0 this will also give us more options for tackling this. However, unless someone wants to send Riq an iPad I can't see anything happening soon.
Just wanted to say I ran a few test on my iPad with a full screen background...(by full I mean 768 x 2000 cause that is what I needed.. And I needed it to move too).
Throwing the thing into a CCSprite I got 30fps.
Same image split into two images 384 x 2000 around 48 fps... but some laggy looking movement. (I'm just scrolling it real slow).
Same image scaled in code to 25% I am getting 60fps.
Split it into 4 images which are 768 x 1000 and tiled = 60 fps.
Taking a 320 x 700 image and scaling in code to 5 x = 30 fps.
FWIW
Has anyone had a chance to play with the blend function on the bg ?
ccBlendFunc bf;
bf.src = GL_ONE;
bf.dst = GL_ZERO;
sprite.blendFunc = bf;If the background image is opaque the performance improvements can be substantial (at least on the iphone) by telling the graphics chip not to worry about transparency.
For what appears to be slightly better performance you can be explicit about how you want the background treated by subclassing CCSprite and within the draw function adding:
if(disableBlend) {
glDisable(GL_BLEND);
}
... draw stuff ...
if(disableBlend) {
glEnable(GL_BLEND);
}I just tried setting the blend function on the background as in your first example. It did help a little.
In my test with a background and no blend function I can add 3-4 sprites before the FPS drops to 50.
With the blend function set I can add 7 sprites before the FPS drops to 50.
With no background I can fill the screen with them... maybe 30+ and no noticeable drop in FPS.
Pat
spawrks
Member
@georgeburns Thanks for the data, thats great work!
I'm wondering if we need a CCBackground class moving forward, that takes an image and separates it into an atlas of smaller images... There has to be a way to tell cocos2d that we want to describe a 'clear' image.
Ok guys, I have the solution for you, I touched upon this sometime ago and people seemed to knock what I said and said it had no use, I've used this method on other systems, PS2, PSX, DreamCast etc....yeah I've been doing a fair amount of time :)
http://www.cocos2d-iphone.org/forum/topic/234
You Split the background into 2 images 1024x512 and 1024x256, this has 2 advantages:
1. you can get the frame rate up to 60fps
2. It takes less memory and more importantly less texture memory.
CCSprite *blah = [CCSprite spriteWithFile:@"menubit1.png"];
[blah setPosition:CGPointMake(256, 512)];
[scene addChild:blah];
CCSprite *blah2 = [CCSprite spriteWithFile:@"menubit2.png"];
[blah2 setPosition:CGPointMake(640, 512)];
[scene addChild:blah2];
I did a test and went from 40fps to 60fps just by that simple change.
Yes and I think it also has something to do with the size of the textures and the texture cache.
If you put a 1024x768 image up the texture that is created is 1024x1024 which is 1MB
If you use the 2 images it creates the textures at the sizes that you asked for and is 768K.
A saving of 256K in Memory and a saving in texture memory also.
Hi,
This is a good thread and show the issues I am having. But it does not seem to solve my problem. Here's the result:
- No background: 60fps
- Put in a 256x768 image: 20fps
- Put in a 512x768 image: 15fps
- Put in both images (to form a complete background): 10fps
Is there a difference using PNG vs JPG? Is there a need to further chopped down the image to smaller size? Thanks!
You must log in to post.
