[iTGB 1.2] Are there any recommendations for getting a build to work on a 3G

#1 Upgrading to 1.3 likely won't change that much.
Your game just very likely is highly unoptimized, be it on the art end (the 3G is significantly more restricted on the RAM - VRAM - CPU - GPU end than the 3GS generation which has impact on loading and rendering speed)

From the symptoms you describe I would assume that two things are required:

1. Transfer of at least the more intense script functions (especially looping and heavy math) to C++
2. Reduction of your art to the targeted platforms level.
The iPhone pre 3GS has 22MB of VRAM at maximum (24MB - 2x framebuffer), RAM wise you can hope for 30MB of RAM with some luck.
A single 1024x1024 thats no pvr basically is 6MB of VRAM (4MB without mipmaps), so 4 of them and it will see the application blow up.
Compression to PVR generaly is a must therefor. It does not only reduce the ram requirements but they also render faster.

These are general hints, for precise input more detailed informations would be required including some statistics on ram - vram usage and benchmark data / profiler output

#2 There isn't much heavy looping except for when I load assets into the $managedDatablockSet and a few timed loops for spawn tracking (triggers every 100ms - one of those things I could streamline). Heavy math is subjective, but I probably do that in my touch tracking routine, when I calculate the distance between the touch and various things. I will look into making that C++.

With regards to PVR, I have a few questions. When it says that PVR must be a power of 2 in length/width, does that mean the final image only, or must I have say a 512x512 cell animation file that I then break down into parts? If it is the latter, we'll run into difficulty since a few of the animations are 12 frames. I suspect it is the latter as well... it would make more sense that way.

As for memory, the entire game is less than 11MB uncompressed, so I don't think we have the memory issue exactly. However, it is clear that something is slowing the game down. I will see what I can do about the various optimizations you suggested and try to streamline my code a bit.

Thanks.

If anyone else has any ideas, please feel free to add them.

#3 PVR - Power of 2: the image file thats being used.
Cells don't end as "real images" in the system :)


I would recommend that you enable the profiler flag in torqueConfig.h and/or use the instruments to profile your code on the device (or both in distinct situations)

one thing that surely will cost serious performance (but should not cause crashes) is collision and usage of the physics system. you can easily kill performance completely that way

#4 The grouping of your sprites inside a sprite sheet also matter - the more bits and pieces which tend to be drawn together, the better. Reports have it switching between textures on the iPhone is slow as molasses :/
(Relatively speaking)

Experimentation is needed on a per-case basis.

#5 Collision is a minimal issue for this game. There are exactly 6 objects on screen at any time that could collide with each other. When the game starts, there's only 3 of them, but it's already sluggish. As for physics, there are 9 objects that use physics, and then it's always path following. These numbers seem really small to me, and quite honestly, they cannot be reduced by design.

Now, I can't necessarily use the script change build, but I could disable physics on a few on screen objects (using setUsesPhysics(false) ). Would that help any?

The main playfield consists of a number of objects:
The background - which is my primary controller. It detects touches, handles spawn tracking, level up, etc.
6 objects to be interacted with - Touch them, and they follow your finger. These are the only collision capable objects in the game. When you aren't moving them, they follow paths.
3 objects that move on paths and animate - They do nothing except those two functions.
6 objects that are mounted on the 3 objects mentioned above - These 6 with the 3 above are the only animated objects in the game. We could trim this to 3 objects mounted if it will help.
2 mute buttons - music and sfx
1 game over screen - Does nothing else to speak of, just gets displayed at the end of the game.
8 text boxes for displaying text - 3 for debugging (will be removed when I no longer need them), 2 for final score info (game over screen related), 1 for level, 1 for current score, 1 for timer.

That's everything.

Now, the background does have a number of behaviors on it to link in those various activities it performs. Two of them have 100ms delayed loops (level up and spawn tracking). I could slow the level up loop to half that (and maybe the spawn tracking also), but beyond that I cannot do without the player wandering why nothing is happening. There is also redundancy of information between them somewhat. I am thinking of merging them.

With regards to profiling, I could do that for a 3GS and one of the new iPod touch devices. However, my access to a 3G is extremely limited. The artist does not live locally, and she is the only team member with one. The only other one is owned by the boyfriend of the designer, who is also not local. So, both 3G phones are not physically available to me, and both owned by non-technical people. Honestly, I think I'm the only tech person on the team... Because of this, any profiling I did would not produce results for a 3G. I am seriously tempted to drop the $600 for a non-contract 3G just so I can *see* what is going wrong.... blah. Maybe if and when this game is a success...

The sprite sheet concern is something I may never be able to resolve. The artist is new to the industry and I have had to try and explain quite a few things to her that seemed like basics (cell animation for one). She is also completely non-technical. Fortunately, I can resize the images locally for the PVR stuff, but getting her to optimize the grouping of sprites will be difficult at best. I'm not sure what optimal is, and I'm sure she doesn't know. That said, she's an awesome artist. Her art is *perfect* for the game. We just have a few hurdles to work out in getting it there.

I want to thank you both for your input. I am starting to get a few more ideas on what I could change to speed it up some.

#6 @ Sarah. A few optimization I've learned from making my game Twistum. To improve FPS you MUST put everything that can into sprite sheets. This will make a big difference in your frame rate. Do not use any GUI objects except for menus.

Using sprite sheets will also help the game load much quicker on the 3g.

I almost finished my game using my 3g only and could get about 35 fps in my game. My load time on the 3g is about 11 seconds, on the 3gs its 4 seconds.