Bigest iTgb acceptable image

#1 The rejection was because of the large version of the icon. You have to have an app icon at 57x57, and a large version of that at 512x512 pixels for use inside the AppStore. Both must be the same image at different sizes. It has nothing to do with in-game graphics (the resolution is only 320x480, anyway).

#2 Actually I have special situation here ,I need only two animation sprites 256x256 with 32 frames that means image size has to be 2048 * 2048 I still can't test performance on iPhone.

I just trying to solve all possible problems
Thanks for answer .

#3 You'll be able to use PVRs more easily with the release of iTGB 1.2, from what I understand. Big spritesheets are good, and they'll fit well in memory with PVR conversion, so you can do it that way just fine.

I tested a 2048x2048 spritesheet turned into 256x256 animation frames, and the memory usage as a PNG was massive. You'll need those PVRs to avoid having your app killed for excess RAM usage.

#4 PVR + cells will not work


The max real texture size on the iphone is 1024x1024 so a 2048x2048 ends as 4x 1024x1024
keep that in mind and best optimize your layout to really use 1024x1024 so you get as few texture switches as possible.

Also check if you really need 256x256 per frame. Thats after all nearly 1/5 of the whole screen space.

#5 Too bad PVR + cells don't work, since almost all animation in a game will use sprite sheets and cells. I'm not even sure how to create a non-cell animation in iTGB... This is a very serious flaw IMO.

#6 Is this pvr/cell issue being fixxed in 1.2, or sometime in the future, or is it the kind of thing that will never work?

#7 it isn't being fixed in 1.2 and from the sounds of it, it would require an entire rewrite of the way cell images are implemented in itgb.

also, pvrs don't work for GUI images.

#8 it does not need much of a rewrite.
Just a fix of one the major "by intend" bottleneck antibehaviors iTGB has.
The idea of cell images is to use a single image and do UV animation.
That reduces the number of texture switches.

What right now seems to happen is that it splits the images into real distinct textures, which does not work with pvr as you don't get pixel data.
None the less, this split is a major bottleneck and needs to be fixed asap

#9 Wow, my head is spinning with the lack of possibilities already :)

#10 ....I really need to sit down and look through the iTGB code. Why the heck is it splitting cell animations into distinct textures. That's pretty silly as it's never ever been necessary to do that for 2D animation for any reason at all. Texture co-ordinates have been around since the old Voodoo cards way back when!

If this is some strange requirement to do with the builder, then I still can't see why it's necessary.

As for changing such strange behaviour (and without looking at the code) I would have said that each frame or static image could simply be stored as an indexed list into a texture. It's not rocket science.

#11 Cocos2D uses the concept of texture atlases. Basically PVR spritesheets. We will need this, since there are 30 million devices out there which randomly crash when you use more than 32MB of RAM ;)

#12 Hey, they might be fixing that major issue. That's why they delayed it!

No? *sigh* Tough luck Lassie.

#13 thanks guys for your reply, I will try to optimize and scale to 1024 *1024

Actually 128 * 128 will do job.

#14

Quote:Hey, they might be fixing that major issue. That's why they delayed it!

Potentially.
Althought I think the chance for that is < 1%
Chances that the delay is related to the delays iTGB doc writting (to get the T3D beta docs done) and the integration of TGBs updated memory handling are much higher.

I think the rendering optimizations, at least unless iTGE is put on ice till iTGB reaches the point of behaving as an iPhone technology is meant to, won't be integrated until iTGB 1.3

#15 I would have thought the memory optimisation was the removal of image splitting. Especially given that this one thing would cause an exponential growth in resource requirements everytime a tileset was loaded.

#16 Exactly. If I have 12 images in a 1024x1024 I now have the requirement that each of my "cells" be a power of 2 instead of each of my "textures" being a power of 2. This could potentially cause a very serious memory issue if you don't design your image cells correctly.