Simulator... as a non-US developer, there is no iPad for development.
The slow down on emulator is very obvious.
Best approach for full-screen background image on iPad
(84 posts) (42 voices)-
demetriusb
MemberDo not look at the physical space that a png is when compressed. For example I have a png that I exported from Photoshop using export for web / devices and it 's at 632 kb physically on disk. When opened it's 3 megs at 1024x1024. The iPhone / iPad reads the "opened" version for lack of a better term. People confuse this all the time.
Demetrius
Posted 1 year ago # -
You cut the pieces into the wrong sizes.
The pieces should be 1024x512 and 1024x256.
You cut them into 768x256 and 768x512 at those sizes they are not a power of 2. (unless you mistyped)
And on the simulator it will run between 10-25fps but on the iPad device it will run at a steady 60fps.
Posted 1 year ago # -
I didn't look at the physical sizes I was stating the memory sizes...except I forgot to multiply by 4!!!
I was having an off day, I should have said 1024x1024 takes up 4mb in memory and the 2 pieces take up 3mb, but hey you save 1mb of texture memory and you get more fps....win win all the way!!
Posted 1 year ago # -
Hi cubiah,
Yes, I mistype, sorry. Like you say, I uses 1024x512 and 1024x256. I also tried cutting horizontally but effect is the same.
The problem is I don't have a real device to test (since it is not available outside US and I am in Singapore), so it is quite worrysome to work on something when the result seems so slow.
Will cutting into smaller sizes help?
Posted 1 year ago # -
ShempLock
Member@Cubla - That is silly, you do not save memory by breaking it up into two textures, whatever gave you that idea? the graphics from BOTH images are needed to refresh one screen, there is no way around that. If it needed to swap out a texture, it would not be able to do it during a single scanline blanking interval. Each frame is made up of 1024 x 768 pixels, breaking the area up into smaller pieces means nothing if the app is refreshing ALL the pixels during each frame update.
Guys, the only reason why it is slow is due to the power of 2 issue, breaking in two fixes that, its not to save you memory :D
Posted 1 year ago # -
Ok another disbeliever....I can only believe that you are not a programmer normally....Before you make such a comment please read other posts and understand how the system works, all textures have to be a power of 2 in the X and the Y, when you have a 1024x768 image it gets expanded in memory to 1024x1024 which by simple maths is bigger than 2 textures of 1024x512 and 1024x256 which both don't get expanded because they are a power of 2 in the X and the Y.
And that still doesn't convince you try writing the code and trace it and see what memory it allocates, it saves you 1Mb in Texture memory and you get the added bonus of increased FPS (which ironically was the reason for this post)
Posted 1 year ago # -
ShempLock
Member@cublah - Try reading my post before making stupid comments. And I have been programming for over 25 years, so please drop the BS comments kid. Nowhere did I say power of 2 is not the root cause! Don't be a wise ass...
And I still suggest 1k x 1k because then you can use compression to save memory, you cannot use compression without SQUARE textures. This is even more true for a static background... so do it his way and save 1mb, do it my way you save more than double that with no speed loss.
Posted 1 year ago # -
@ShempLock
Lol kid! I've been writing games since 1981. I wasn't being a wise ass I was just stating facts.I ran the tests before I posted and using a 1024x1024 texture does not save more memory.
If you use a 1024x1024 texture for the background you do not get the speed increase, using 2 textures decreases the memory footprint and the amount of texture memory (unless Apple's tools are not correct with the numbers).
Posted 1 year ago # -
@cublah Not sure if you knew this already, but iPad, iPhone 3GS, and iPod Touch 2G all support non power of two textures, so you should get the best performance by using an image at the native resolution like 1024x768 or 320x480.
I don't have an iPad, so I cannot test this. If you have some time would you mind comparing performance of your two POT image approach versus a single native resolution image? (NOTE that only the latest Cocos2D will let you use NPOT textures w/o padding them up to POT sizes). Thanks :)
Posted 1 year ago # -
ShempLock
Member@cublah you are not correct, if the background is static, you are BY FAR better off using a 1k x 1k compressed texture than breaking it into two. My "Kid" comment is because you are a wise ass and are condescending. If you want to toss numbers around, I have been developing LONGER than you. I have a suggestion for you: Treat people with respect and you may get some respect yourself. Do not talk down to others here when they might know more than you do!
Posted 1 year ago # -
ShempLock, your initial comment seemed to kick it off and now it seems you want the last word. This is probably the most important ipad related thread on here thus far so lets put the posturing aside and stick to a technical discussion going forward. You both win (or lose).
Posted 1 year ago # -
I think ShempLock is trying suggest using a square texture in combination with the PVR technology.....
Without PVR it seems like the splitting of the texture would give you both speed and memory... however CJ brings up a good point about that non-power-of-two support, has anyone tested this for a fact?
Posted 1 year ago # -
@jd
You are quite correct nobody wins.I provided a solution for what people wanted and just added that it saves you some memory as well, I got shot down for stating that.
I think mobilebros might be right, my solution is for full color images that usually won't compress well which is what I thought people where asking about, if I'm wrong about that then I apologize. PVR compressed textures in my experience never look too good unless they have limited color and not a lot of detail.
When I get back to my Mac I will test the POT flag and let you know.
Posted 1 year ago # -
ShempLock
MemberNPOT is always slower.
Considering this thread did not mention anything about full color high res digital photography, I suggest PVR and square textures for the best speed assuming the background is static. Way less memory and you can't get any faster rendering.
BTW cublah, its not so much that I disagree with you, its just the way you respond with an attitude as if you are somehow better than everyone else here (you aren't). I suggest you and I both leave this thread on topic, and just deal with the fact that we are BOTH RIGHT.
Posted 1 year ago # -
I finally broke down an bought an iPad to test (in Singapore, it is easily double the price paid in US!).
The game with full background - no splitting into multiple images - runs at 15fps in simulator but 50fps in iPad hardware! So I am happy and did not do any changes.
Posted 1 year ago # -
Petey_Pii
Memberjust as a side note, if you guys are using a cccolorlayer rather than a cclayer it takes a big chunk out of performance as well. if you're using a full sized background definitely use just a regular cclayer. i saw performance go from 50fps to a solid 60fps (device)
Posted 1 year ago # -
yaoligang
MemberMaybe a solution:
I found this is very interesting.
The cocos2d version used is 0.99.4rc3. The game has a lot of sprites and buttons(menuitem). Big performance difference for just several lines of codes. The codes are in CCLayer subclass.
Codes with < 45 FPS on iPad:
CCSprite *sp = [CCSprite spriteWithFile:@"Background.png"]; sp.position = ccp(1024/2, 768/2); [self addChild:sp];Codes with 60 FPS on iPad:
CCSprite *spback = [(CCSprite*)[CCSprite alloc] init]; [self addChild:spback]; CCSprite *sp = [CCSprite spriteWithFile:@"Background.png"]; sp.position = ccp(1024/2, 768/2); [spback addChild:sp];Note: If I add the background to the CCLayer directly, the FPS drops a lot. But if I add a empty CCSprite to the CCLayer and add the background to the empty CCSprite, the performance is much better. Why???????
Posted 1 year ago # -
Reply »
You must log in to post.